[RESOLU] Blocage d'IP incompréhensible

Support Debian
#1

Bonjour à tous

J’ai un serveur debian 8.3 avec gitlab installé dessus.

Ce serveur est uniquement destiné à un usage local donc aucune regle iptable n’est en place, c’est parfaitement vierge

Tous les postes qui se connectent sur la plateforme git via le port 80, se connectent sans soucis sauf 1 et 1 seul qui ne peut pas se connecter.

Voila ou j’en suis:

Le PC ne reçoit pas de réponse au ping du serveur
Le serveur me dit: From ipduserveur icmp_seq=1 Destination Host Unreachable

Un TCPdump sur le serveur me dit qu’il reçoit effectivement les demandes de reponse au ping du PC
mais de son coté le serveur ne répond pas aux pings, le tcpdump me confirme bien que le serveur ne répond pas

Sur ce PC (qui est sous Ubuntu 14.04LTS), il y a une vm windows sous virtualbox et donc j’ai fait un test en lançant windows
quand la VM est configurée en NAT, pas d’accés au serveur
quand la VM est configurée en bridge, aucun soucis pour accéder au serveur

Donc il y a bien un soucis de “blacklisting” de l’ip du PC, mais le serveur debian est vraiment une installation de base et je n’ai pas ajouté de protection du type fail2ban.

Voila donc pourquoi je fais appel à vous pour un coup de main car je ne vois pas quel est l’origine du probleme et comment le résoudre.

Par avance merci

#2

Pourrait-on avoir la configuration réseau exacte de ce fameux PC ?

cat  /etc/network/interfaces

A moins que monsieur Ubuntu a encore changé et utilise autre chose pour configurer le réseau.

De même sur le serveur, vérifier que les fichiers de hosts_access(5) sont vides

fp2x@drhpcmsa:~$ grep -v -e '^#'  /etc/hosts.allow

fp2x@drhpcmsa:~$ grep -v -e '^#'  /etc/hosts.allow

fp2x@drhpcmsa:~$

Cela ne va pas arranger les choses. Vous parlez de soucis de "blacklisting" de l'ip du PC sans préciser de quelle IP il s’agit. on ne peut pas deviner.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« L’amour, c’est comme les spaghettis, quand c’est mou, c’est cuit. »
Proverbe belge

#3

Le serveur envoie quand même bien un message d’erreur ICMP “Destination unreachable” pour que le PC affiche ce message ?

“Destination Host unreachable” est un message d’erreur ICMP qui signale la plupart du temps l’échec de la résolution d’adresse du noeud réseau suivant. En temps normal, par définition ce type de message ne peut provenir que d’un routeur intermédiaire ou de la machine source, pas de la machine de destination.
Qu’affichent
iptables-save ip route
sur le serveur ?

@littlejohn75 : A ma connaissance "destination host unreachable " ne peut être causé par /etc/hosts.{allow,deny}

#4

Merci pour votre coup de main

voila les infos

@littlejohn75

voila le retour de cat /etc/network/interfaces sur le PC bloqué

cat  /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
dns-search mondomaine.lan
##the IP address of your domain controller
dns-nameservers 172.16.0.253 172.16.0.2 172.16.0.5

Pour les config réseau des postes clients, je reste sur la bonne vieille méthode qui fonctionne toujours :wink:

et voila en complement le retour de ifconfig:

eth0      Link encap:Ethernet  HWaddr f8:ca:b8:47:b6:f7
          inet adr:10.1.0.115  Bcast:10.1.0.255  Masque:255.255.255.0
          adr inet6: fe80::faca:b8ff:fe47:b6f7/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:1765471 erreurs:0 :0 overruns:0 frame:0
          TX packets:999934 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:2165967282 (2.1 GB) Octets transmis:165745221 (165.7 MB)
          Interruption:20 Mémoire:f7d00000-f7d20000

lo        Link 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:65536  Metric:1
          Packets reçus:557409 erreurs:0 :0 overruns:0 frame:0
          TX packets:557409 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          Octets reçus:118589965 (118.5 MB) Octets transmis:118589965 (118.5 MB)

grep -v -e ‘^#’ /etc/hosts.allow est vide.

Cela ne va pas arranger les choses. Vous parlez de soucis de “blacklisting” de l’ip du PC sans préciser de quelle IP il s’agit. on ne peut pas deviner.

L’IP de la machine est 10.1.0.115, quand la vm est en NAT pas d’accés au serveur a partir de la vm windows, quand la VM est en bridge avec donc son IP 10.1.0.236, il y a connexion au serveur.

@PascalHambourg

Voila les retours sur le serveur:

iptables-save
# Generated by iptables-save v1.4.21 on Wed Aug 24 14:51:49 2016
*nat
:PREROUTING ACCEPT [13459:1675449]
:INPUT ACCEPT [9924:984967]
:OUTPUT ACCEPT [529:52580]
:POSTROUTING ACCEPT [529:52580]
COMMIT
# Completed on Wed Aug 24 14:51:49 2016
# Generated by iptables-save v1.4.21 on Wed Aug 24 14:51:49 2016
*filter
:INPUT ACCEPT [12032390:2281718630]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [3711384:2282160722]
COMMIT
# Completed on Wed Aug 24 14:51:49 2016

et

ip route
default via 172.16.0.254 dev eth0
172.16.0.0/24 dev eth0  proto kernel  scope link  src 172.16.0.102

la connexion entre le serveur et le PC “bloqué” passe par un vpn watchguard, mais d’autres PC situés au même endroit (donc ayant la même plage ip en 10.1.0.xxx) accèdent au serveur sans aucun soucis.

#5

C’est-à-dire ? Apparamment pas celle basée sur le fichier interfaces puisque celui-ci ne configure que l’interface de loopback.

Et pour ma question concernant tcpdump ?

#6

ben oui dans le fichier interface je n’entre que les nom du domaine et serveur dns puisque tout le systeme est sous active directory.

Les machines clientes se debrouillent très bien avec le dhcp. Pour les serveurs la oui je passe en IP fixe via le fichiers /etc/network/interfaces.

A tu voulais les retour de tcpdump a partir du serveur !!! Pas de soucis je te met cela demain matin :wink:

#7

Quel est le rapport entre le contenu de ce fichier interfaces et Active Directory ? Ce n’est pas Active Directory qui configure les interfaces.

Possible, mais pas via ce fichier interfaces. Donc via NetworkManager ou autre.
Et si elles se débrouillent si bien avec le DHCP, pourquoi avoir besoin de spécifier le domaine de recherche et les DNS dans le fichier interfaces ?

#8

simplement j’utilise openpbis pour faire entrer mes machines dans active directory

et le protocole d’installation impose qu’il y ai cette modification au niveau du fichier interfaces.

J’ai toujours fait comme cela et mes machines sont dans le domaine sans aucun soucis.

Si ça fonctionne je ne me pose pas plus de questions ^^

#9

@PascalHambourg

voila les résultats:

a partir du PC 10.1.0.115

ping 172.16.0.102
PING 172.16.0.102 (172.16.0.102) 56(84) bytes of data. 
pas de réponse

sur le serveur résultat de:

tcpdump -i eth0 src 10.1.0.115 and dst 172.16.0.102
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:42:41.769448 IP 10.1.0.115 > 172.16.0.102: ICMP echo request, id 18929, seq 103, length 64
11:42:42.769694 IP 10.1.0.115 > 172.16.0.102: ICMP echo request, id 18929, seq 104, length 64
11:42:43.769589 IP 10.1.0.115 > 172.16.0.102: ICMP echo request, id 18929, seq 105, length 64
11:42:44.770841 IP 10.1.0.115 > 172.16.0.102: ICMP echo request, id 18929, seq 106, length 64
4 packets captured
4 packets received by filter
0 packets dropped by kernel

deuxieme phase

ping à partir du serveur vers le PC:

ping 10.1.0.115
PING 10.1.0.115 (10.1.0.115) 56(84) bytes of data.
From 172.16.0.102 icmp_seq=1 Destination Host Unreachable
From 172.16.0.102 icmp_seq=2 Destination Host Unreachable
From 172.16.0.102 icmp_seq=3 Destination Host Unreachable
^C
--- 10.1.0.115 ping statistics ---
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5030ms
pipe 3

et pendant ce temps là, commande lancée à partir du serveur:

tcpdump -i eth0 src 172.16.0.102 and dst 10.1.0.115
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Je ne trouve vraiment pas la raison de ce soucis

#10

Ah, je n’avais pas compris dans ton message initial que le message “destination host unreachable” se produisait lorsque c’est le serveur qui essaie d’envoyer un ping vers le PC.

Le premier message se produit-il immédiatement ou après quelques secondes de délai ?
EDIT : d’après le nombre de paquets émis et le temps d’exécution, il y a eu un délai. Donc a priori le serveur a envoyé une requête ARP pour résoudre l’adresse du prochain saut (passerelle) mais n’a pas obtenu de réponse.

Tes critères de capture de tcpdump sont trop restrictifs. Ils excluent les paquets de réponse (où src et dst sont intervertis), les paquets d’erreur qui ont une autre adresse source, les paquets ARP de résolution d’adresse.

Je voudrais, sur le serveur :

  • la capture des paquets ARP sans critère d’adresse lors d’une tentative de ping du serveur vers le PC
  • le contenu du cache ARP affiché par
    arp -n
    ou
    ip -4 neigh
  • le résultat du routage initial de l’adresse du PC depuis le client affiché par
    ip route get 10.1.0.115
  • les règles de routage affichées par
    ip rule
  • le contenu de toutes les tables de routage IPv4 affiché par
    ip -4 route ls table all

EDIT : Et la même chose (sauf les deux dernières commandes) avec l’adresse d’un autre PC en 10.1.0.x joignable pour comparaison.

#11

Merci pour ton coup de main, donc voila les résultats:

déja la base:

arp -a
xxx.domaine.lan (172.16.0.145) at bc:30:5b:da:16:b0 [ether] on eth0
xxx.domaine.lan (172.16.0.135) at f0:1f:af:3e:fa:e8 [ether] on eth0
xxx.domaine.lan (172.16.0.2) at 44:a8:42:42:29:87 [ether] on eth0
xxx.domaine.lan (172.16.0.141) at 98:90:96:c9:08:1d [ether] on eth0
xxx.domaine.lan (172.16.0.110) at 00:15:5d:00:02:1d [ether] on eth0
xxx.domaine.lan (172.16.0.253) at 00:15:5d:00:fd:00 [ether] on eth0
xxx.domaine.lan (172.16.0.120) at 00:1a:a0:22:55:35 [ether] on eth0
xxx.domaine.lan (172.16.0.81) at 00:15:5d:00:02:0f [ether] on eth0
xxx.domaine.lan (172.16.0.101) at <incomplete> on eth0
xxx.domaine.lan (172.16.0.139) at a4:ba:db:ab:ea:18 [ether] on eth0
xxx.domaine.lan (172.16.0.133) at 00:25:64:c9:67:e0 [ether] on eth0
? (172.16.0.50) at 00:11:32:36:2b:d5 [ether] on eth0
? (172.16.0.85) at 00:15:5d:00:02:2c [ether] on eth0
? (172.16.0.254) at 00:90:7f:1f:09:31 [ether] on eth0
xxx.domaine.lan (172.16.0.130) at d4:be:d9:22:85:49 [ether] on eth0
xxx.domaine.lan (172.16.0.136) at 00:1e:c9:35:3a:5d [ether] on eth0
xxx.domaine.lan (172.16.0.147) at 08:00:27:d1:25:c6 [ether] on eth0
? (172.16.0.143) at 00:26:b9:80:2b:4e [ether] on eth0
? (172.16.0.134) at 5c:26:0a:81:58:5c [ether] on eth0
? (172.16.0.140) at d4:be:d9:3e:dd:e4 [ether] on eth0
xxx.domaine.lan (172.16.0.144) at 08:00:27:01:a2:03 [ether] on eth0
? (172.16.0.116) at 00:15:5d:00:02:14 [ether] on eth0
xxx.domaine.lan (172.16.0.137) at 74:e6:e2:49:7c:e6 [ether] on eth0

ensuite

arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
172.16.0.145             ether   bc:30:5b:da:16:b0   C                     eth0
172.16.0.135             ether   f0:1f:af:3e:fa:e8   C                     eth0
172.16.0.2               ether   44:a8:42:42:29:87   C                     eth0
172.16.0.141             ether   98:90:96:c9:08:1d   C                     eth0
172.16.0.110             ether   00:15:5d:00:02:1d   C                     eth0
172.16.0.253             ether   00:15:5d:00:fd:00   C                     eth0
172.16.0.120             ether   00:1a:a0:22:55:35   C                     eth0
172.16.0.81              ether   00:15:5d:00:02:0f   C                     eth0
172.16.0.101                     (incomplete)                              eth0
172.16.0.139             ether   a4:ba:db:ab:ea:18   C                     eth0
172.16.0.133             ether   00:25:64:c9:67:e0   C                     eth0
172.16.0.50              ether   00:11:32:36:2b:d5   C                     eth0
172.16.0.85              ether   00:15:5d:00:02:2c   C                     eth0
172.16.0.254             ether   00:90:7f:1f:09:31   C                     eth0
172.16.0.130             ether   d4:be:d9:22:85:49   C                     eth0
172.16.0.136             ether   00:1e:c9:35:3a:5d   C                     eth0
172.16.0.147             ether   08:00:27:d1:25:c6   C                     eth0
172.16.0.143             ether   00:26:b9:80:2b:4e   C                     eth0
172.16.0.134             ether   5c:26:0a:81:58:5c   C                     eth0
172.16.0.140             ether   d4:be:d9:3e:dd:e4   C                     eth0
172.16.0.144             ether   08:00:27:01:a2:03   C                     eth0
172.16.0.116             ether   00:15:5d:00:02:14   C                     eth0
172.16.0.137             ether   74:e6:e2:49:7c:e6   C                     eth0

ensuite

ip route get 10.1.0.115
10.1.0.115 via 172.16.0.101 dev eth0  src 172.16.0.102
    cache <redirected>

ensuite

ip rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

ensuite

ip -4 route ls table all
default via 172.16.0.254 dev eth0
172.16.0.0/24 dev eth0  proto kernel  scope link  src 172.16.0.102
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1
broadcast 172.16.0.0 dev eth0  table local  proto kernel  scope link  src 172.16.0.102
local 172.16.0.102 dev eth0  table local  proto kernel  scope host  src 172.16.0.102
broadcast 172.16.0.255 dev eth0  table local  proto kernel  scope link  src 172.16.0.102

maintenant la partie avec un ping qui fonctionne sur la plage 10.1.0.xxx

voila la validation du ping

ping 10.1.0.80
PING 10.1.0.80 (10.1.0.80) 56(84) bytes of data.
64 bytes from 10.1.0.80: icmp_seq=1 ttl=62 time=20.4 ms
64 bytes from 10.1.0.80: icmp_seq=2 ttl=62 time=19.8 ms
64 bytes from 10.1.0.80: icmp_seq=3 ttl=62 time=24.9 ms
^C
--- 10.1.0.80 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 19.886/21.745/24.947/2.279 ms

et donc maintenant les autres résultats:

ip route get 10.1.0.80
10.1.0.80 via 172.16.0.254 dev eth0  src 172.16.0.102
    cache

ensuite

arp -n

reste parfaitement identique

#12

RAS dans les règles et tables de routage.
Par contre le cache de routage indique que le trafic pour 10.1.0.115 est redirigé vers 172.16.0.101 au lieu de la passerelle par défaut 172.16.0.254. Et le cache ARP indique que 172.16.0.101 ne répond pas aux requêtes ARP, d’où le message d’erreur “host unreachable” et l’impossibilité d’envoyer des paquets IP à cette adresse.

Pour l’autre adresse, le cache de routage indique de passer par la passerelle par défaut.

Une idée d’à quoi correspond cette adressee 172.16.0.101 ?

Une route de redirection pour une adresse IP est généralement mise en place à la suite de la réception d’un paquet ICMP de type “redirect” par un routeur intermédiaire (normalement le premier, donc la passerelle par défaut en réponse à un paquet envoyé à cette adresse.

Pour le confirmer, il faudrait vider le cache de routage avec
ip route flush cache
vérifier que le routage de l’adresse IP est redevenu par défaut avec
ip route get 10.1.0.115
lancer une capture de trafic de tous les paquets ICMP, refaire un ping vers 10.1.0.115 et examiner la capture à la recherche de paquets ICMP redirect.

EDIT : S’il y a un ICMP redirect, vérifier la configuration de routage du routeur émetteur.

1 J'aime
#13

genial ça fonctionne de nouveau

Cette IP 172.16.0.101 c’est ma VM VPN de secours, mais elle est arrêtée donc là j’hallucine un peu quand même.

la je viens de faire tourner plus de 10 minutes un
tcpdump -nni eth0 icmp en même temps qu’un ping vers 10.1.0.115, et pas de redirect

15:15:43.730707 IP 172.16.0.102 > 10.1.0.115: ICMP echo request, id 20534, seq 1, length 64
15:15:43.755281 IP 10.1.0.115 > 172.16.0.102: ICMP echo reply, id 20534, seq 1, length 64
15:15:44.732476 IP 172.16.0.102 > 10.1.0.115: ICMP echo request, id 20534, seq 2, length 64
15:15:44.752250 IP 10.1.0.115 > 172.16.0.102: ICMP echo reply, id 20534, seq 2, length 64
15:15:45.734366 IP 172.16.0.102 > 10.1.0.115: ICMP echo request, id 20534, seq 3, length 64
15:15:45.754201 IP 10.1.0.115 > 172.16.0.102: ICMP echo reply, id 20534, seq 3, length 64

Bon en tout cas, la prochaine fois je saurais vers où chercher.

Pour le moment je ne vois vraiment pas pourquoi c’est parti en vrille.

merci beaucoup Pascal pour ton aide

#14

La route a été supprimée par le flush cache et n’est pas revenue. La seule explication que je vois est que cette route a été créée par un ICMP redirect reçu alors que le VPN de secours était actif. J’ignore combien de temps ce type de route reste dans le cache de routage du noyau.

Tu peux configurer le serveur pour ne pas accepter les ICMP redirect afin d’éviter que cela se reproduise. Cependant le routage ne sera pas optimal : au lieu d’envoyer directement au routeur indiqué par le redirect, la machine continuera à envoyer au routeur par défaut qui fera suivre.

Pour une machine non configurée en routeur, il faut que /proc/sys/net/ipv4/conf/all/accept_redirects et /proc/sys/net/ipv4/conf/eth0/accept_redirects soient à 0.

1 J'aime
#15

merci pour cette astuce

Bon je vais voir si cela se reproduit.

Si c’est le cas, à ce moment là pas de pitié, je mettrais les 2 fichiers à 0.

encore merci :wink:

#16

Attention ce ne sont pas de vrais fichiers, comme tout ce qui est dans /proc et /sys, ce qu’on y écrit n’est pas persistant. Il faut le faire à chaque démarrage par exemple via /etc/sysctl.conf ou /etc/sysctl.d/*.conf

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

(la dernière ligne sert à définir la valeur par défaut qui sera affectée aux interfaces pas encore créées, au cas où eth0 n’existerait pas encore)

ou avec une commande up dans /etc/network/interfaces si l’interface est configurée dans ce fichier.

iface eth0 inet (...)
up echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
up echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_redirects

Autres options, tout aussi volatiles :

  • désactiver l’envoi d’ICMP redirect sur le routeur par défaut (avec /proc/sys/net/ipv4/conf/*/send_redirects si Linux, même principe)
  • bloquer les ICMP redirect en sortie sur le routeur ou en entrée sur le serveur avec iptables ou équivalent

iptables -I INPUT -p icmp --icmp-type redirect -j DROP

PS : il y a une case à cliquer quelque part pour marquer le sujet comme résolu.

#17

merci pour cette précision bien utile en effet :yum:

la cloture du sujet est tellement bien caché que je ne le trouve pas :smile:

#18

En bas du message qui a résolu ton problème, il suffit de cliquer sur la coche ;-).