Voici le problème que j'essaie de résoudre. Il y a un serveur ("système distant") que je peux connecter depuis mon ordinateur local mais ce système distant n'a pas de connexion Internet. Je veux fournir au système distant un accès à Internet via mon ordinateur local en utilisant un VPN basé sur ssh. Comment est-ce que j'accomplis ceci? J'ai essayé ce qui suit, qui semble fonctionner partiellement. Ce que je veux dire par «fonctionne partiellement», c'est que les paquets de connexion (paquets de synchronisation) sont envoyés à mon ordinateur local mais ne parviennent pas à établir la connexion à Internet. J'utilise tcpdump pour capturer des paquets sur un ordinateur local. L'ordinateur local et le système distant exécutent tous les deux centos 7.
La configuration - Remarque: les commandes ci-dessous sont exécutées dans l'ordre. Les commandes user @ remote sont exécutées sur le serveur distant et les commandes user @ local sont exécutées sur l'ordinateur local.
[utilisateur @ distant ~] $ ip addr show
1: lo: mtu 65536 état de file d'attente qdisc INCONNU
lien / bouclage 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valid_lft forever forever_lft forever
inet6 :: Hôte de portée 1/128
valid_lft forever forever_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast état UP qlen 1000
liaison / éther AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 portée globale dynamique eth0
valid_lft 1785sec Preferred_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 portée dynamique noprefixroute globale
valid_lft 2591987sec Preferred_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: Lien de portée LLLL / 64
valid_lft forever forever_lft forever
[utilisateur @ local ~] $ ip addr show
1: lo: mtu 65536 état de file d'attente qdisc INCONNU
lien / bouclage 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valid_lft forever forever_lft forever
inet6 :: Hôte de portée 1/128
valid_lft forever forever_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast état UP qlen 1000
liaison / éther AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 portée globale dynamique eth0
valid_lft 1785sec Preferred_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 portée dynamique noprefixroute globale
valid_lft 2591987sec Preferred_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: Lien de portée LLLL / 64
valid_lft forever forever_lft forever
Créez l'interface tun0 sur le système distant .
[user @ remote ~] $ sudo ip tuntap add tun0 mode tun
[utilisateur @ distant ~] $ ip addr show
1: lo: mtu 65536 état de file d'attente qdisc INCONNU
lien / bouclage 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valid_lft forever forever_lft forever
inet6 :: Hôte de portée 1/128
valid_lft forever forever_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast état UP qlen 1000
liaison / éther AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 portée globale dynamique eth0
valid_lft 1785sec Preferred_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 portée dynamique noprefixroute globale
valid_lft 2591987sec Preferred_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: Lien de portée LLLL / 64
valid_lft forever forever_lft forever
3: tun0: mtu 1500 qdisc noop state DOWN qlen 500
lien / aucun
Créez l'interface tun0 sur le système local .
[utilisateur @ local ~] $ sudo ip tuntap ajouter tun0 mode tun
[utilisateur @ local ~] $ ip addr show
1: lo: mtu 65536 état de file d'attente qdisc INCONNU
lien / bouclage 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valid_lft forever forever_lft forever
inet6 :: Hôte de portée 1/128
valid_lft forever forever_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast état UP qlen 1000
liaison / éther AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 portée globale dynamique eth0
valid_lft 1785sec Preferred_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 portée dynamique noprefixroute globale
valid_lft 2591987sec Preferred_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: Lien de portée LLLL / 64
valid_lft forever forever_lft forever
3: tun0: mtu 1500 qdisc noop state DOWN qlen 500
lien / aucun
Attribuez une adresse IP à tun0 et affichez-la:
[utilisateur @ local ~] $ sudo ip addr add 10.0.2.1/30 dev tun0
[utilisateur @ local ~] $ sudo ip link set dev tun0 up
[utilisateur @ local ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast état BAS qlen 500
lien / aucun
inet 10.0.2.1/30 scope global tun0
valid_lft forever forever_lft forever
[user @ remote ~] $ sudo ip addr add 10.0.2.2/30 dev tun0
[user @ remote ~] $ sudo ip link set dev tun0 up
[utilisateur @ distant ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast état BAS qlen 500
lien / aucun
inet 10.0.2.2/30 scope global tun0
valid_lft forever forever_lft forever
Modifiez sshd_config sur les systèmes distants et locaux pour activer le tunneling:
[utilisateur @ distant ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config PermitTunnel point à point
[utilisateur @ local ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config PermitTunnel point à point
Créez le tunnel ssh:
[utilisateur @ local ~] $ sudo ssh -f -w0: 0 root @ remote true mot de passe root @ remote: [utilisateur @ local ~] $ ps aux | grep root @ remote racine 1851 0,0 0,0 76112 1348? SS 23:12 0:00 ssh -f -w0: 0 root @ remote true
Testez le ping sur les deux serveurs en utilisant les nouvelles adresses IP:
[utilisateur @ local ~] $ ping 10.0.2.2 -c 2 PING 10.0.2.2 (10.0.2.2) 56 (84) octets de données. 64 octets à partir de 10.0.2.2: icmp_seq = 1 ttl = 64 temps = 1,68 ms 64 octets à partir de 10.0.2.2: icmp_seq = 2 ttl = 64 temps = 0,861 ms --- 10.0.2.2 statistiques ping --- 2 paquets transmis, 2 reçus, 0% de perte de paquets, temps 1002 ms rtt min / moy / max / mdev = 0,861 / 1,274 / 1,688 / 0,415 ms
[utilisateur @ distant ~] $ ping 10.0.2.1 -c 2 PING 10.0.2.1 (10.0.2.1) 56 (84) octets de données. 64 octets à partir de 10.0.2.1: icmp_seq = 1 ttl = 64 temps = 0,589 ms 64 octets à partir de 10.0.2.1: icmp_seq = 2 ttl = 64 temps = 0,889 ms --- 10.0.2.1 statistiques ping --- 2 paquets transmis, 2 reçus, 0% de perte de paquets, temps 1000 ms rtt min / moy / max / mdev = 0,589 / 0,739 / 0,889 / 0,150 ms
[utilisateur @ distant ~] $ route Table de routage IP du noyau Destination Gateway Genmask Flags Metric Ref Use Iface passerelle par défaut 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 [utilisateur @ distant ~] $ ip route show par défaut via AAA.BBB.CCC.1 dev eth0 proto statique métrique 100 10.0.2.0/30 dev tun0 proto kernel scope link src 10.0.2.2 AAA.BBB.CCC.0 / 24 dev eth0 proto kernel scope link src AAA.BBB.CCC.31 metric 100
Obtenez des adresses IP Google:
[utilisateur @ local ~] $ nslookup google.com Serveur: serveur Adresse: serveur # 53 Réponse sans autorité: Nom: google.com Adresse: 173.194.219.101 Nom: google.com Adresse: 173.194.219.100 Nom: google.com Adresse: 173.194.219.113 Nom: google.com Adresse: 173.194.219.102 Nom: google.com Adresse: 173.194.219.139 Nom: google.com Adresse: 173.194.219.138
IMPORTANT: j'ai exécuté la commande ci-dessus à un moment différent et j'ai obtenu un résultat différent. Ne présumez pas que votre réponse sera la même que la mienne pour nslookup ci-dessus.
Étant donné que toutes les adresses IP de Google commencent par 173.194.219, permet de router toutes ces adresses IP via l'ordinateur local.
[user @ remote ~] $ sudo ip route add 173.194.219.0/24 dev tun0 [utilisateur @ distant ~] $ route Table de routage IP du noyau Destination Gateway Genmask Flags Metric Ref Use Iface passerelle par défaut 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 173.194.219.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 [utilisateur @ distant ~] $ ip route show par défaut via AAA.BBB.CCC.1 dev eth0 proto statique métrique 100 10.0.2.0/30 dev tun0 proto kernel scope link src 10.0.2.2 AAA.BBB.CCC.0 / 24 dev eth0 proto kernel scope link src AAA.BBB.CCC.31 metric 100 173.194.219.0/24 dev tun0 scope link
Activez ip_forwarding:
[utilisateur @ local ~] $ grep ip_forward /etc/sysctl.conf net.ipv4.ip_forward = 1 [user @ local ~] Redémarrage du réseau de service $ sudo Redémarrage du réseau (via systemctl): [OK]
Configurez la capture des paquets sur l'ordinateur local à l'aide de tcpdump:
[utilisateur @ local ~] $ sudo tcpdump -nn -vv 'port not 22' -i any tcpdump: écoute sur n'importe quel type de lien LINUX_SLL (Linux cuit), taille de capture 65535 octets
Essayez de vous connecter à Google à partir du serveur distant.
[utilisateur @ distant ~] $ openssl s_client -connect google.com:443 socket: pas de route vers l'hôte connect: errno = 113
Dès que la commande openssl est exécutée sur le serveur distant, le tcpdump capture certains paquets:
10.0.2.2.52768> 173.194.219.102.443: drapeaux [S], cksum 0x8702 (correct), seq 994650730, win 29200, options [mss 1460, sackOK, TS val 7701438 ecr 0, nop, wscale 7], longueur 0
00: 49: 33.247753 IP (tos 0x0, ttl 64, id 46037, offset 0, drapeaux [DF], proto TCP (6), longueur 60)
10.0.2.2.48774> 173.194.219.100.443: drapeaux [S], cksum 0x47a7 (correct), seq 2218733674, win 29200, options [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], longueur 0
00: 49: 33.247883 IP (tos 0xc0, ttl 64, id 9538, décalage 0, drapeaux [aucun], proto ICMP (1), longueur 88)
10.0.2.1> 10.0.2.2: hôte ICMP 173.194.219.100 inaccessible - administrateur interdit, longueur 68
IP (tos 0x0, ttl 63, id 46037, offset 0, drapeaux [DF], proto TCP (6), longueur 60)
10.0.2.2.48774> 173.194.219.100.443: drapeaux [S], cksum 0x47a7 (correct), seq 2218733674, win 29200, options [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], longueur 0
00: 49: 33.253068 IP (tos 0x0, ttl 64, id 26282, offset 0, drapeaux [DF], proto TCP (6), longueur 60)
10.0.2.2.51312> 173.194.219.101.443: drapeaux [S], cksum 0x6ff8 (correct), seq 2634016105, win 29200, options [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], longueur 0
00: 49: 33.254771 IP (tos 0xc0, ttl 64, id 9539, décalage 0, drapeaux [aucun], proto ICMP (1), longueur 88)
10.0.2.1> 10.0.2.2: hôte ICMP 173.194.219.101 inaccessible - administrateur interdit, longueur 68
IP (tos 0x0, ttl 63, id 26282, offset 0, drapeaux [DF], proto TCP (6), longueur 60)
10.0.2.2.51312> 173.194.219.101.443: drapeaux [S], cksum 0x6ff8 (correct), seq 2634016105, win 29200, options [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], longueur 0
00: 49: 33.258805 IP (tos 0x0, ttl 64, id 9293, décalage 0, drapeaux [DF], proto TCP (6), longueur 60)
10.0.2.2.33686> 173.194.219.139.443: drapeaux [S], cksum 0x542b (correct), seq 995927943, win 29200, options [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], longueur 0
00: 49: 33.258845 IP (tos 0xc0, ttl 64, id 9540, offset 0, drapeaux [aucun], proto ICMP (1), longueur 88)
10.0.2.1> 10.0.2.2: hôte ICMP 173.194.219.139 inaccessible - administrateur interdit, longueur 68
IP (tos 0x0, ttl 63, id 9293, offset 0, drapeaux [DF], proto TCP (6), longueur 60)
10.0.2.2.33686> 173.194.219.139.443: drapeaux [S], cksum 0x542b (correct), seq 995927943, win 29200, options [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], longueur 0
^ C
13 paquets capturés
13 paquets reçus par filtre
0 paquets abandonnés par le noyau
Les paquets capturés à l'aide de tcpdump suggèrent qu'une tentative est faite pour établir la connexion (des paquets de synchronisation sont envoyés) mais rien n'est reçu. Il y a aussi un message 10.0.2.1 > 10.0.2.2: ICMP host 173.194.219.139 unreachable - admin prohibited, length 68qui semble suggérer un problème.
Des suggestions sur la façon de contourner ce problème? Y a-t-il des règles iptables qui doivent être ajoutées? Des problèmes de pare-feu (pare-feu-d?).
Note # 1
Sortie de iptables-save:
[utilisateur @ local ~] $ sudo iptables -t nat -A POSTROUTING -s 10.0.2.2/32! -d 10.0.2.1/30 -j MASQUERADE -o eth0 [utilisateur @ local ~] $ sudo iptables-save # Généré par iptables-save v1.4.21 le sam 15 avr 01:40:57 2017 * nat : PRÉROUVER ACCEPTER [35: 8926] : ENTRÉE ACCEPTER [1:84] : SORTIE ACCEPTER [6: 439] : ACCEPTATION POSTROUTE [6: 439] : OUTPUT_direct - [0: 0] : POSTROUTING_ZONES - [0: 0] : POSTROUTING_ZONES_SOURCE - [0: 0] : POSTROUTING_direct - [0: 0] : POST_public - [0: 0] : POST_public_allow - [0: 0] : POST_public_deny - [0: 0] : POST_public_log - [0: 0] : PREROUTING_ZONES - [0: 0] : PREROUTING_ZONES_SOURCE - [0: 0] : PREROUTING_direct - [0: 0] : PRE_public - [0: 0] : PRE_public_allow - [0: 0] : PRE_public_deny - [0: 0] : PRE_public_log - [0: 0] -A PREROUTING -j PREROUTING_direct -A PREROUTING -j PREROUTING_ZONES_SOURCE -A PREROUTING -j PREROUTING_ZONES -A SORTIE -j SORTIE_direct -A POSTROUTING -j POSTROUTING_direct -A POSTROUTING -j POSTROUTING_ZONES_SOURCE -A POSTROUTING -j POSTROUTING_ZONES -A POSTROUTING -s 10.0.2.2/32! -d 10.0.2.0/30 -j MASQUERADE -A POSTROUTING_ZONES -o eth0 -g POST_public -A POSTROUTING_ZONES -g POST_public -A POST_public -j POST_public_log -A POST_public -j POST_public_deny -A POST_public -j POST_public_allow -A PREROUTING_ZONES -i eth0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow COMMETTRE # Terminé le sam.15 avril 01:40:57 2017 # Généré par iptables-save v1.4.21 le sam 15 avr 01:40:57 2017 *mutiler : PRÉROUVER ACCEPTER [169: 18687] : ENTRÉE ACCEPTER [144: 11583] : AVANCE ACCEPTER [0: 0] : SORTIE ACCEPTER [80: 8149] : ACCEPTATION POSTROUTE [80: 8149] : FORWARD_direct - [0: 0] : INPUT_direct - [0: 0] : OUTPUT_direct - [0: 0] : POSTROUTING_direct - [0: 0] : PREROUTING_ZONES - [0: 0] : PREROUTING_ZONES_SOURCE - [0: 0] : PREROUTING_direct - [0: 0] : PRE_public - [0: 0] : PRE_public_allow - [0: 0] : PRE_public_deny - [0: 0] : PRE_public_log - [0: 0] -A PREROUTING -j PREROUTING_direct -A PREROUTING -j PREROUTING_ZONES_SOURCE -A PREROUTING -j PREROUTING_ZONES -A INPUT -j INPUT_direct -A FORWARD -j FORWARD_direct -A SORTIE -j SORTIE_direct -A POSTROUTING -j POSTROUTING_direct -A PREROUTING_ZONES -i eth0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow COMMETTRE # Terminé le sam.15 avril 01:40:57 2017 # Généré par iptables-save v1.4.21 le sam 15 avr 01:40:57 2017 *Sécurité : ENTRÉE ACCEPTER [2197: 163931] : AVANCE ACCEPTER [0: 0] : SORTIE ACCEPTER [1229: 185742] : FORWARD_direct - [0: 0] : INPUT_direct - [0: 0] : OUTPUT_direct - [0: 0] -A INPUT -j INPUT_direct -A FORWARD -j FORWARD_direct -A SORTIE -j SORTIE_direct COMMETTRE # Terminé le sam.15 avril 01:40:57 2017 # Généré par iptables-save v1.4.21 le sam 15 avr 01:40:57 2017 *brut : PRÉROUVER ACCEPTER [2362: 184437] : SORTIE ACCEPTER [1229: 185742] : OUTPUT_direct - [0: 0] : PREROUTING_direct - [0: 0] -A PREROUTING -j PREROUTING_direct -A SORTIE -j SORTIE_direct COMMETTRE # Terminé le sam.15 avril 01:40:57 2017 # Généré par iptables-save v1.4.21 le sam 15 avr 01:40:57 2017 *filtre : ENTRÉE ACCEPTER [0: 0] : AVANCE ACCEPTER [0: 0] : SORTIE ACCEPTER [80: 8149] : FORWARD_IN_ZONES - [0: 0] : FORWARD_IN_ZONES_SOURCE - [0: 0] : FORWARD_OUT_ZONES - [0: 0] : FORWARD_OUT_ZONES_SOURCE - [0: 0] : FORWARD_direct - [0: 0] : FWDI_public - [0: 0] : FWDI_public_allow - [0: 0] : FWDI_public_deny - [0: 0] : FWDI_public_log - [0: 0] : FWDO_public - [0: 0] : FWDO_public_allow - [0: 0] : FWDO_public_deny - [0: 0] : FWDO_public_log - [0: 0] : INPUT_ZONES - [0: 0] : INPUT_ZONES_SOURCE - [0: 0] : INPUT_direct - [0: 0] : IN_public - [0: 0] : IN_public_allow - [0: 0] : IN_public_deny - [0: 0] : IN_public_log - [0: 0] : OUTPUT_direct - [0: 0] -A INPUT -m conntrack --ctstate RELATED, ESTABLISHED -j ACCEPT -A ENTRÉE -i lo -j ACCEPTER -A INPUT -j INPUT_direct -A ENTRÉE -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -j REJECT --reject-with icmp-host-prohibed -A FORWARD -m conntrack --ctstATE RELATED, ESTABLISHED -j ACCEPT -A AVANT -i lo -j ACCEPTER -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -j REJECT --reject-with icmp-host-prohibed -A SORTIE -j SORTIE_direct -A FORWARD_IN_ZONES -i eth0 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_OUT_ZONES -o eth0 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FWDI_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDI_public -p icmp -j ACCEPT -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A INPUT_ZONES -i eth0 -g IN_public -A INPUT_ZONES -g IN_public -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public -p icmp -j ACCEPTER -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NOUVEAU -j ACCEPTER COMMETTRE # Terminé le sam.15 avril 01:40:57 2017
Remarque n ° 2:
J'ai configuré un serveur Web Apache sur un hôte distinct auquel seul le serveur local a accès. J'ai exécuté tcpdump sur le serveur Web en écoutant sur le port 80. Lorsque je lance,
telnet webserver 80je capture les paquets suivants. Il s'agit d'un comportement attendu car la connexion TCP est établie (S, S-Ack, Ack).
[user @ webserver ~] $ sudo tcpdump -nn -vv 'port pas 22 et 80' -i eth0
tcpdump: écoute sur eth0, EN10MB de type lien (Ethernet), taille de capture 65535 octets
07: 17: 30.411474 IP (tos 0x10, ttl 64, id 34376, décalage 0, drapeaux [DF], proto TCP (6), longueur 60)
local.server.46710> web.server.80: drapeaux [S], cksum 0x8412 (incorrect -> 0x6d96), seq 3018586542, win 29200, options [mss 1460, sackOK, TS val 3047398 ecr 0, nop, wscale 7] , longueur 0
07: 17: 30.411557 IP (tos 0x0, ttl 64, id 0, offset 0, drapeaux [DF], proto TCP (6), longueur 60)
web.server.80> local.server.46710: drapeaux [S.], cksum 0x8412 (incorrect -> 0x9114), seq 2651711943, ack 3018586543, win 28960, options [mss 1460, sackOK, TS val 37704524 ecr 3047398, nop , wscale 7], longueur 0
07: 17: 30.411725 IP (tos 0x10, ttl 64, id 34377, décalage 0, drapeaux [DF], proto TCP (6), longueur 52)
local.server.46710> web.server.80: drapeaux [.], cksum 0x840a (incorrect -> 0x301c), seq 1, ack 1, win 229, options [nop, nop, TS val 3047398 ecr 37704524], longueur 0
Lorsque j'essaie de me connecter au serveur Web à partir du serveur distant via le serveur local, tcpdump sur le serveur Web ne capture aucun paquet (pas même la synchronisation initiale) mais le serveur local capture le paquet de synchronisation envoyé au serveur Web (voir ci-dessous). Cela me fait croire que quelque chose empêche les paquets d'être envoyés au serveur Web - peut-être une mauvaise configuration ou un pare-feu.
[utilisateur @ local ~] $ sudo tcpdump -nn -vv 'port pas 22 et 80' -i tout
tcpdump: écoute sur n'importe quel type de lien LINUX_SLL (Linux cuit), taille de capture 65535 octets
02: 24: 09.135842 IP (tos 0x10, ttl 64, id 38062, décalage 0, drapeaux [DF], proto TCP (6), longueur 60)
10.0.2.2.50558> web.server.80: drapeaux [S], cksum 0x668d (correct), seq 69756226, win 29200, options [mss 1460, sackOK, TS val 4780524 ecr 0, nop, wscale 7], longueur 0
IMPORTANT: les paquets ne sont pas acheminés via eth0 mais à la place, une tentative est faite pour envoyer les paquets au serveur web via tun0 (qui échoue). Je peux le confirmer en exécutant tcpdump sur l'interface tun0:
[user @ local ~] $ sudo tcpdump -nn -vv 'port pas 22 et 80' -i tun0
tcpdump: écoute sur tun0, RAW de type lien (IP brute), taille de capture 65535 octets
02: 28: 10.295972 IP (tos 0x10, ttl 64, id 46976, décalage 0, drapeaux [DF], proto TCP (6), longueur 60)
10.0.2.2.50560> webserver.80: drapeaux [S], cksum 0xd560 (correct), seq 605366388, win 29200, options [mss 1460, sackOK, TS val 5021684 ecr 0, nop, wscale 7], longueur 0
Remarque n ° 3:
j'ai désactivé le pare-feu sur l'ordinateur local et les paquets de synchronisation ont été reçus par le serveur Web.
[utilisateur @ local ~] $ sudo systemctl stop firewalld
[user @ webserver ~] $ sudo tcpdump -nn -vv 'port pas 22 et 80' -i eth0
tcpdump: écoute sur eth0, EN10MB de type lien (Ethernet), taille de capture 65535 octets
08: 25: 17.390912 IP (tos 0x10, ttl 63, id 61767, décalage 0, drapeaux [DF], proto TCP (6), longueur 60)
10.0.2.2.50580> web.server.80: drapeaux [S], cksum 0x30dc (correct), seq 2601927549, win 29200, options [mss 1460, sackOK, TS val 7123514 ecr 0, nop, wscale 7], longueur 0
08: 25: 17.391003 IP (tos 0x0, ttl 64, id 0, offset 0, drapeaux [DF], proto TCP (6), longueur 60)
web.server.80> 10.0.2.2.50580: drapeaux [S.], cksum 0x4e23 (incorrect -> 0xa316), seq 959115533, ack 2601927550, win 28960, options [mss 1460, sackOK, TS val 41771503 ecr 7123514, nop , wscale 7], longueur 0
08: 25: 17.391192 IP (tos 0x0, ttl 128, id 60032, offset 0, drapeaux [aucun], proto TCP (6), longueur 40)
10.0.2.2.50580> web.server.80: drapeaux [R], cksum 0x7339 (correct), seq 2601927550, win 8192, longueur 0
08: 25: 18.393794 IP (tos 0x10, ttl 63, id 61768, décalage 0, drapeaux [DF], proto TCP (6), longueur 60)
10.0.2.2.50580> web.server.80: drapeaux [S], cksum 0x2cf1 (correct), seq 2601927549, win 29200, options [mss 1460, sackOK, TS val 7124517 ecr 0, nop, wscale 7], longueur 0
08: 25: 18.393898 IP (tos 0x0, ttl 64, id 0, offset 0, drapeaux [DF], proto TCP (6), longueur 60)
web.server.80> 10.0.2.2.50580: drapeaux [S.], cksum 0x4e23 (incorrect -> 0x7e71), seq 974785773, ack 2601927550, win 28960, options [mss 1460, sackOK, TS val 41772506 ecr 7124517, nop , wscale 7], longueur 0
08: 25: 18.394003 IP (tos 0x0, ttl 128, id 60033, décalage 0, drapeaux [aucun], proto TCP (6), longueur 40)
10.0.2.2.50580> web.server.80: drapeaux [R], cksum 0x566a (correct), seq 2601927550, win 8192, longueur 0
Désormais, il est clair que l'IP source doit être mise à jour pour correspondre à l'adresse IP du serveur local avant que le paquet ne soit envoyé au serveur Web. Comme l'a suggéré @xin, NAT doit être configuré sur le serveur local.
Remarque # 4:
Une fois que j'essaie de me connecter au serveur Web, je peux voir que le nombre de paquets pour la règle 9 augmente de 1 (comme indiqué ci-dessous).
[utilisateur @ local ~] $ sudo iptables -nvL --line-numéros .......... Chain FORWARD (la politique ACCEPTE 0 paquets, 0 octets) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPTER tout - * * 0.0.0.0/0 0.0.0.0/0 ctstate LIÉ, ÉTABLI 2 0 0 ACCEPTER tout - lo * 0.0.0.0/0 0.0.0.0/0 3 1 60 FORWARD_direct all - * * 0.0.0.0/0 0.0.0.0/0 4 1 60 FORWARD_IN_ZONES_SOURCE tous - * * 0.0.0.0/0 0.0.0.0/0 5 1 60 FORWARD_IN_ZONES tous - * * 0.0.0.0/0 0.0.0.0/0 6 1 60 FORWARD_OUT_ZONES_SOURCE tous - * * 0.0.0.0/0 0.0.0.0/0 7 1 60 FORWARD_OUT_ZONES tous - * * 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP all - * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID 9 1 60 REJET tout - * * 0.0.0.0/0 0.0.0.0/0 rejeter-avec icmp-host-prohibé .......... [utilisateur @ local ~] $ sudo iptables -D FORWARD 9
Une fois la règle 9 de la chaîne FORWARD supprimée (d'en haut, comme @xin l'a suggéré), je peux me connecter au serveur Web.
[utilisateur @ local ~] $ sudo iptables -nvL --line-numéros .......... Chain FORWARD (la politique ACCEPTE 1 paquets, 60 octets) num pkts bytes target prot opt in out source destination 1 12 5857 ACCEPTER tout - * * 0.0.0.0/0 0.0.0.0/0 ctstate LIÉ, ÉTABLI 2 0 0 ACCEPTER tout - lo * 0.0.0.0/0 0.0.0.0/0 3 2120 FORWARD_direct all - * * 0.0.0.0/0 0.0.0.0/0 4 2120 FORWARD_IN_ZONES_SOURCE tous - * * 0.0.0.0/0 0.0.0.0/0 5 2120 FORWARD_IN_ZONES tous - * * 0.0.0.0/0 0.0.0.0/0 6 2120 FORWARD_OUT_ZONES_SOURCE tous - * * 0.0.0.0/0 0.0.0.0/0 7 2120 FORWARD_OUT_ZONES tous - * * 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP all - * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID ..........
iptables-savesortie de la machine locale?-A FORWARD -j REJECT --reject-with icmp-host-prohibited. les paquets arrivant sur votre machine et ayant une adresse de destination hors de votre machine, iront à la chaîne FORWARD, alors abandonnez cette règle.