depuis mon passage en dégroupage partiel chez Free, le ping ne répond plus vers l’extérieur et pourtant la liaison Net est bonne, la preuve, j’écris de mon ordi.
Quand je ping ma propre Ip, ça fonctionne mais si j’essaie avec yahoo.fr, free.fr ou d’autres adresses IP, je reste bloqué à la deuxième ligne.
[code]ricardo@sid-hda8:~$ ping free.fr
PING free.fr (212.27.48.10) 56(84) bytes of data.
[/code]
Je patauge. 
IOP,
les tests
"ping 194.2.0.50" et “ping google.fr” ne passent pas…
ben surmement le firewall qui bloque les ping… (icmp)
non, aucun ne passe et pourtant, je n’ai rien changé à mon firewall ?
IOP,
t’a quoi comme modem/routeur?
si c’est une freebox, t’es sur qu’il l’on pas mis a jour…
Bonjour et bonne année
N’y aurait -il pas un problème avec /etc/resolv.conf ?
Est-ce que ifconfig te renvoies bien les deux interfaces lo et eth0 ?
Il y a ce qu’il faut dans KDE (kcontrol) ou Gnome pour refaire la config : moins élégant mais plus rapide.
Meilleures salutations.
IOP,
ca m’etonne que ca soit ca… car il ne pourrai pas surfer du tt si les DNS marchait po… et puis le PING @IP ne marche pas non plus…
Internet = Bon et ifconfig répond bien aussi. mon port étant sur eth1, eth0 n’étant pas branché en ce moment et réservé au lan.
[code]ricardo@sid-hda8:~$ sudo ifconfig
Mot de passe :
eth1 Lien encap:Ethernet HWaddr 00:08:54:3E:A2:91
inet adr:88.xxxx.yy.zzz Bcast:88.xxx.yy.255 Masque:255.255.255.0
adr inet6: fe80::208:54ff:fe3e:a291/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:337390 errors:0 dropped:0 overruns:0 frame:0
TX packets:487622 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:120654797 (115.0 MiB) TX bytes:366113350 (349.1 MiB)
Interruption:16 Adresse de base:0x8400
lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:71 errors:0 dropped:0 overruns:0 frame:0
TX packets:71 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:5986 (5.8 KiB) TX bytes:5986 (5.8 KiB)[/code]
par contre, je me pingue très bien sur 88.xxx.yy.zzz
Je n’ai pas necore eu le tps d’aller voir sur le pare-feu, c’est ptet là que ça déconne mais alors pourquoi ça fonctionnait avant le dégroupage ???
Effectivement, c’est peut-être ton pare-feu qui bloque l’ICMP.
Sinon, dans l’interface d’administration Free, il y a une case à cocher qui active/désactive le ping.
Mon IP est 82.66.248.156 donc ma passerelle free est 82.66.248.254, et le ping vers 82.66.248.254 fonctionne toujours.
Essaye pour toi. Sinon regarde si par hasard la freebox ne bloquerait pas les pings mais ce serait étonnant.
Essaye aussi de faire un traceroute vers google par exemple.
Pas mieux sur ton Ip François.
pour Google :
ricardo@sid-hda8:~$ traceroute 209.85.135.104
traceroute to 209.85.135.104 (209.85.135.104), 30 hops max, 40 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
ricardo@sid-hda8:~$
Mon parefeu : ligne “-A INPUT -p icmp -j DROP” = problème
je ne pense pas car elle a tjrs été présente.
[code]# Generated by iptables-save v1.3.8 on Sat Jan 12 02:23:17 2008
*raw
:PREROUTING ACCEPT [1717:1428738]
:OUTPUT ACCEPT [1644:240075]
COMMIT
*mangle
:PREROUTING ACCEPT [1717:1428738]
:INPUT ACCEPT [1717:1428738]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1644:240075]
:POSTROUTING ACCEPT [1659:243095]
COMMIT
*nat
:PREROUTING ACCEPT [9:544]
:POSTROUTING ACCEPT [175:12462]
:OUTPUT ACCEPT [175:12462]
COMMIT
*filter
:INPUT DROP [24:3564]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1644:240075]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4662 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4242 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 119 -j ACCEPT
-A INPUT -p udp -m udp --dport 4241 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 6881 -j ACCEPT
-A INPUT -p udp -m udp --dport 4444 -j ACCEPT
COMMIT
[/code]
Plutôt, oui. Forcément, avec cette règle les outils comme ping et traceroute, dont le fonctionnement se base sur des réponses ICMP, marchent beaucoup moins bien. Cela peut aussi causer des problèmes de MTU puisque les ICMP signalant qu’un paquet est trop gros sont bloqués. Pour finir, cela bloque les ICMP signalant un problème réseau (destination unreachable, time exceeded…).
Il faudrait au moins la mettre après la règle qui accepte les paquets ESTABLISHED,RELATED, voire la supprimer puisque la politique par défaut de la chaîne est DROP de toute façon.
Bloquer ICMP, c’est MAL !
oui, je m’en suis rendu compte car j’ai fait l’essai sous une Etch où il n’y a pas de parefeu et tout pingue.
Ma question est quand m^ :
pourquoi Matt m’avait fait placer cette ligne quand il m’avait aidé à construire un parefeu (voir fil ds T&A : iptables pour les nuls)
Désolé, je n’ai pas retrouvé où Matt a suggéré cette règle, au milieu du monceau de réponses “philosophiques” et interminables dont on se demande ce qu’elles viennent faire dans les trucs & astuces. Parce contre j’ai bien vu la mise en garde fort justifiée de Thialme concernant celle-ci.
Si on a vraiment peur des ICMP, le strict minimum qu’il faut accepter est les types destination-unreachable, time-exceeded et parameter-problem, tous dans l’état RELATED, qui correspondent à des messages d’erreur liés à des connexions existantes. Sinon on s’expose à des ennuis. Si on veut recevoir les réponses aux pings, il faut aussi accepter le type echo-reply dans l’état ESTABLISHED.
Mai si on a déjà une règle qui accepte tout ce qui est dans l’état ESTABLISHED ou RELATED, cela englobe tout ce qui précède et bien plus.
[quote=“ricardo”]
pourquoi Matt m’avait fait placer cette ligne quand il m’avait aidé à construire un parefeu (voir fil ds T&A : iptables pour les nuls)[/quote]
Peut-être car beaucoup de gens veulent interdire le ping et que c’est plus facile dans un tel tutorial de faire un DROP sur tout le protocole ICMP, plutôt que d’aller approfondir dessus et d’y perdre les gens.
bon je dirait que l’icpm ne risque plus grand chose, excepter un flood, il suffi donc de limiter a 30 requête par heure avec iptables. concernant son internet je dirait que sa va peut être disparaître avec
les protocoles ipv6 qui arrive gentiment mai surement 
iptables -m limit --help
-
limit v1.3.8 options:
--limit avg max average match rate: default 3/hour
[Packets per second unless followed by
/sec /minute /hour /day postfixes]
--limit-burst number number to match in a burst, default 5Alors voilà ce que j’ai fait et qui permet de pinguer correctement tout mais j’attends vosremarques :
J’ai suivi le conseil de PascalHambourg en supprimant icmp de sa place initiale et en le rajoutant. Il se retrouve donc de ce fait en fin de liste.
En effet, ds ce cas, ette ligne est-elle vraiment utile puisque la règle des INPUT est DROP donc en rajoutant cette ligne, je ne fait qu’un doublon, non ?
[quote]ricardo@sid-hda8:~$ sudo iptables-save
Mot de passe :
*filter
:INPUT DROP [20:3042]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [9644:6240594]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4662 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4242 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 119 -j ACCEPT
-A INPUT -p udp -m udp --dport 4241 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 6881 -j ACCEPT
-A INPUT -p udp -m udp --dport 4444 -j ACCEPT
-A INPUT -p icmp -j DROP
COMMIT
*nat
REROUTING ACCEPT [56:2935]
OSTROUTING ACCEPT [647:42694]
:OUTPUT ACCEPT [647:42694]
COMMIT
*mangle
REROUTING ACCEPT [6589:2894151]
:INPUT ACCEPT [6589:2894151]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [9644:6240594]
OSTROUTING ACCEPT [9659:6243331]
COMMIT
*raw
REROUTING ACCEPT [6589:2894151]
:OUTPUT ACCEPT [9644:6240594]
COMMIT
ricardo@sid-hda8:~$ [/quote]
Votre avis sur mon parefeu final ?
Attention à ne pas réduire tout ICMP au seul ping (echo request). L’echo request n’est qu’un des nombreux types ICMP. Il ne faut évidemment pas limiter les types qui signalent des erreurs mais les filtrer avec l’état RELATED.
[quote]concernant son internet je dirait que sa va peut être disparaître avec
les protocoles ipv6 qui arrive gentiment mai surement
[/quote]
Pas vraiment, puisque IPv6 arrive avec sa version d’ICMP, ICMPv6, qui reprend grosso modo les mêmes principes et types qu’en IPv4. ICMPv6 gagne même de l’importance par rapport à la version v4 puisqu’il réalise en plus l’équivalent du protocole ARP.
ricardo : En effet cette règle en fin de chaîne fait doublon avec la politique par défaut de la chaîne.
suffi :slightly_smiling:
Par contre tu filtres pas les sorties. point a noter, ce qui veux dire que tou peux sortir.
ceci dit c'est pas indispensable, pour au temps que tu n'installes que ce qui est open-sources.suffi
Par contre tu filtres pas les sorties. point a noter, ce qui veux dire que tou peux sortir.
ceci dit c’est pas indispensable, pour au temps que tu n’installes que ce qui est open-sources.
OK, merci de vos réponses ,je vais faire.