Comment créer / configurer vpn en utilisant uniquement SSH?

Voici le problème que j'essaie de résoudre. Il y a un server ("système distant") que je suis capable de ssh depuis mon ordinateur local mais ce système distant n'a pas de connection internet. Je veux fournir au système distant un access à Internet via mon ordinateur local en utilisant le VPN ssh. Comment est-ce que j'accomplis ceci? J'ai essayé ce qui suit, qui semble fonctionner partiellement. Ce que je veux dire par «travail partiel» est que les packages de connection (packages de synchronisation) sont envoyés à mon ordinateur local mais échouent à établir la connection à Internet. J'utilise tcpdump pour capturer des packages sur un ordinateur local. L'ordinateur local et le système distant sont tous les deux des centos 7.

La configuration – Note: les commands ci-dessous sont exécutées dans l'ordre. Les commands user @ remote sont exécutées sur le server distant et les commands user @ local sont exécutées sur l'ordinateur local.

  [user @ distant ~] $ ip addr show
 1: lo: mtu 65536 qdisc noqueue state UNKNOWN 
     lien / bouclage 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
     inet 127.0.0.1/8 scope hôte lo
        valid_lft toujours préféré_lft pour toujours
     inet6 :: 1/128 scope hôte 
        valid_lft toujours préféré_lft pour toujours
 2: eth0: mtu 1500 qdisc pfifo_fast état UP qlen 1000
     lien / éther AA: BB: CC: DD: FF: ff fd: ff: ff: ff: ff: ff
     inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope dynamic globale eth0
        valide_lft 1785sec preferred_lft 1785sec
     inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope globale noprefixroute dynamic 
        valide_lft 2591987sec preferred_lft 604787sec
     inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 Lien de périmètre 
        valid_lft toujours préféré_lft pour toujours
  [user @ local ~] $ ip addr show
 1: lo: mtu 65536 qdisc noqueue state UNKNOWN 
     lien / bouclage 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
     inet 127.0.0.1/8 scope hôte lo
        valid_lft toujours préféré_lft pour toujours
     inet6 :: 1/128 scope hôte 
        valid_lft toujours préféré_lft pour toujours
 2: eth0: mtu 1500 qdisc pfifo_fast état UP qlen 1000
     lien / éther AA: BB: CC: DD: FF: ff fd: ff: ff: ff: ff: ff
     inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope dynamic globale eth0
        valide_lft 1785sec preferred_lft 1785sec
     inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope globale noprefixroute dynamic 
        valide_lft 2591987sec preferred_lft 604787sec
     inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 Lien de périmètre 
        valid_lft toujours préféré_lft pour toujours

Créez l'interface tun0 sur le système distant .

  [user @ distant ~] $ sudo ip tuntap append tun0 mode tun
 [user @ distant ~] $ ip addr show
 1: lo: mtu 65536 qdisc noqueue state UNKNOWN 
     lien / bouclage 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
     inet 127.0.0.1/8 scope hôte lo
        valid_lft toujours préféré_lft pour toujours
     inet6 :: 1/128 scope hôte 
        valid_lft toujours préféré_lft pour toujours
 2: eth0: mtu 1500 qdisc pfifo_fast état UP qlen 1000
     lien / éther AA: BB: CC: DD: FF: ff fd: ff: ff: ff: ff: ff
     inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope dynamic globale eth0
        valide_lft 1785sec preferred_lft 1785sec
     inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope globale noprefixroute dynamic 
        valide_lft 2591987sec preferred_lft 604787sec
     inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 Lien de périmètre 
        valid_lft toujours préféré_lft pour toujours
 3: tun0: mtu 1500 qdisc état de noop DOWN qlen 500
     lien / aucun 

Créez l'interface tun0 sur le système local .

  [user @ local ~] $ sudo ip tuntap append tun0 mode tun
 [user @ local ~] $ ip addr show
 1: lo: mtu 65536 qdisc noqueue state UNKNOWN 
     lien / bouclage 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
     inet 127.0.0.1/8 scope hôte lo
        valid_lft toujours préféré_lft pour toujours
     inet6 :: 1/128 scope hôte 
        valid_lft toujours préféré_lft pour toujours
 2: eth0: mtu 1500 qdisc pfifo_fast état UP qlen 1000
     lien / éther AA: BB: CC: DD: FF: ff fd: ff: ff: ff: ff: ff
     inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope dynamic globale eth0
        valide_lft 1785sec preferred_lft 1785sec
     inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope globale noprefixroute dynamic 
        valide_lft 2591987sec preferred_lft 604787sec
     inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 Lien de périmètre 
        valid_lft toujours préféré_lft pour toujours
 3: tun0: mtu 1500 qdisc état de noop DOWN qlen 500
     lien / aucun

Atsortingbuez une adresse IP à tun0 et montez-la:

  [user @ local ~] $ sudo ip addr append 10.0.2.1/30 dev tun0
 [user @ local ~] $ sudo ip lien set dev tun0 up
 [user @ local ~] $ ip addr afficher tun0
 3: tun0: mtu 1500 qdisc pfifo_fast état DOWN qlen 500
     lien / aucun 
     inet 10.0.2.1/30 scope global tun0
        valid_lft toujours préféré_lft pour toujours 
  [user @ distant ~] $ sudo ip addr append 10.0.2.2/30 dev tun0
 [user @ distant ~] $ sudo ip lien set dev tun0 up
 [user @ distant ~] $ ip addr afficher tun0
 3: tun0: mtu 1500 qdisc pfifo_fast état DOWN qlen 500
     lien / aucun 
     inet 10.0.2.2/30 scope global tun0
        valid_lft toujours préféré_lft pour toujours

Modifiez sshd_config sur les systèmes distant et local pour activer le tunnelage:

  [user @ distant ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config 
 PermitTunnel point à point 
  [user @ local ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config 
 PermitTunnel point à point

Créez le tunnel ssh:

  [user @ local ~] $ sudo ssh -f -w0: 0 root @ distant true
 mot de passe root @ remote: 
 [user @ 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 ping sur les deux servers en utilisant les nouvelles adresses IP:

  [user @ 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 fois = 1,68 ms
 64 octets à partir de 10.0.2.2: icmp_seq = 2 ttl = 64 fois = 0,861 ms

 --- 10.0.2.2 ping statistics ---
 2 packages transmis, 2 reçus, 0% de perte de packages, 1002 ms de time
 rtt min / moy / max / mdev = 0,861 / 1,274 / 1,688 / 0,415 ms
  [user @ remote ~] $ 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 fois = 0,589 ms
 64 octets à partir de 10.0.2.1: icmp_seq = 2 ttl = 64 fois = 0.889 ms

 --- 10.0.2.1 ping statistics ---
 2 packages transmis, 2 reçus, 0% de perte de packages, 1000 ms de time
 rtt min / moy / max / mdev = 0,589 / 0,739 / 0,888 / 0,150 ms 
 [user @ remote ~] $ route
 Table de routing IP du kernel
 Destination Gateway Genmask Drapeaux Mésortingque Ref Utilisation 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
 [user @ remote ~] $ ip route show
 défaut via AAA.BBB.CCC.1 dev eth0 proto statique mésortingque 100 
 10.0.2.0/30 dev tun0 proto kernel scope lien src 10.0.2.2 
 AAA.BBB.CCC.0 / 24 dev eth0 proto kernel scope link src AAA.BBB.CCC.31 mésortingque 100 

Obtenez des adresses IP Google:

 [user @ local ~] $ nslookup google.com
 Serveur: server
 Adresse: server # 53

 Réponse non autorisée:
 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 command ci-dessus à une heure différente 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.

Puisque toutes les adresses IP de Google commencent par 173.194.219, permet d'apather toutes ces adresses IP à travers l'ordinateur local.

 [user @ distant ~] $ sudo ip route add 173.194.219.0/24 dev tun0
 [user @ remote ~] $ route
 Table de routing IP du kernel
 Destination Gateway Genmask Drapeaux Mésortingque Ref Utilisation 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
 [user @ remote ~] $ ip route show
 défaut via AAA.BBB.CCC.1 dev eth0 proto statique mésortingque 100 
 10.0.2.0/30 dev tun0 proto kernel scope lien src 10.0.2.2 
 AAA.BBB.CCC.0 / 24 dev eth0 proto kernel scope link src AAA.BBB.CCC.31 mésortingque 100 
 173.194.219.0/24 dev tun0 scope link 

Activer ip_forwarding:

 [user @ local ~] $ grep ip_forward /etc/sysctl.conf 
 net.ipv4.ip_forward = 1
 [user @ local ~] $ sudo service network restart
 Redémarrage du réseau (via systemctl): [OK]

Configurez la capture de packages sur un ordinateur local à l'aide de tcpdump:

 [user @ local ~] $ sudo tcpdump -nn -vv 'port non 22' -i tout
 tcpdump: écoute sur n'importe quel type LINUX_SLL (Linux cuit), taille de capture 65535 octets

Essayez de vous connecter à Google à partir du server distant.

 [user @ distant ~] $ openssl s_client -connect google.com:443
 socket: Pas de route vers l'hôte
 se connecter: errno = 113

Dès que la command openssl est exécutée sur le server distant, le tcpdump capture certains packages:

     10.0.2.2.52768> 173.194.219.102.443: drapeaux [S], cksum 0x8702 (correct), seq 994650730, win 29200, options [mss 1460, sackOK, TSval 7701438 écr 0, nop, wscale 7], longueur 0
 00: 49: 33.247753 IP (tos 0x0, ttl 64, id 46037, décalage 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, TSval 7701439 écr 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 - admin interdit, longueur 68
     IP (tos 0x0, ttl 63, id 46037, décalage 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, TSval 7701439 écr 0, nop, wscale 7], longueur 0
 00: 49: 33.253068 IP (tos 0x0, ttl 64, id 26282, décalage 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, TSval 7701443 écrivent 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 - admin interdit, longueur 68
     IP (tos 0x0, ttl 63, id 26282, décalage 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, TSval 7701443 écrivent 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, TSval 7701450 écr 0, nop, wscale 7], longueur 0
 00: 49: 33.258845 IP (tos 0xc0, ttl 64, id 9540, décalage 0, drapeaux [aucun], proto ICMP (1), longueur 88)
     10.0.2.1> 10.0.2.2: hôte ICMP 173.194.219.139 inaccessible - admin interdit, longueur 68
     IP (tos 0x0, ttl 63, 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, TSval 7701450 écr 0, nop, wscale 7], longueur 0
 ^ C
 13 packages capturés
 13 packages reçus par le filter
 0 packages déposés par le kernel

Les packages capturés à l'aide de tcpdump suggèrent qu'une tentative est faite pour établir la connection (les packages 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 68 qui 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 à append? Tous les problèmes de pare-feu (pare-feu-d?).


Note 1
Sortie d'iptables-save:

 [user @ local ~] $ sudo iptables -t nat -A POSTROUTING -s 10.0.2.2/32!  -d 10.0.2.1/30 -j MASQUERADE -o eth0
 [user @ local ~] $ sudo iptables-save
 # Généré par iptables-save v1.4.21 le Sam Apr 15 01:40:57 2017
 * nat
 : PREROUTING ACCEPT [35: 8926]
 : ENTRÉE ACCEPTER [1:84]
 : OUTPUT ACCEPT [6: 439]
 : POSTROUTING ACCEPT [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
 -U OUTPUT -j OUTPUT_direct
 -A POSTROUTING -j POSTROUTING_direct
 -A POSTROUTING -j POSTROUTING_ZONES_SOURCE
 -Une POSTROUTING -j POSTROUTING_ZONES
 -Une 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 Apr 15 01:40:57 2017
 # Généré par iptables-save v1.4.21 le Sam Apr 15 01:40:57 2017
 *mutiler
 : PREROUTING ACCEPTER [169: 18687]
 : ENTRÉE ACCEPTER [144: 11583]
 : ACCEPTER AVANT [0: 0]
 : OUTPUT ACCEPT [80: 8149]
 : POSTROUTING ACCEPT [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
 -U OUTPUT -j OUTPUT_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 Apr 15 01:40:57 2017
 # Généré par iptables-save v1.4.21 le Sam Apr 15 01:40:57 2017
 *Sécurité
 : ENTRÉE ACCEPTER [2197: 163931]
 : ACCEPTER AVANT [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
 -U OUTPUT -j OUTPUT_direct
 COMMETTRE
 # Terminé le Sam Apr 15 01:40:57 2017
 # Généré par iptables-save v1.4.21 le Sam Apr 15 01:40:57 2017
 *brut
 : PREROUTING ACCEPT [2362: 184437]
 : SORTIE ACCEPTER [1229: 185742]
 : OUTPUT_direct - [0: 0]
 : PREROUTING_direct - [0: 0]
 -A PREROUTING -j PREROUTING_direct
 -U OUTPUT -j OUTPUT_direct
 COMMETTRE
 # Terminé le Sam Apr 15 01:40:57 2017
 # Généré par iptables-save v1.4.21 le Sam Apr 15 01:40:57 2017
 *filter
 : ENTRÉE ACCEPTER [0: 0]
 : ACCEPTER AVANT [0: 0]
 : OUTPUT ACCEPT [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 LIÉ, ÉTABLI -j ACCEPTE
 -A INPUT -i lo -j ACCEPTER
 -A INPUT -j INPUT_direct
 -A INPUT -j INPUT_ZONES_SOURCE
 -A INPUT -j INPUT_ZONES
 -A INPUT -m conntrack --ctstate INVALID -j DROP
 -A INPUT -j REJECT --reject-avec icmp-host-prohibited
 -A FORWARD -m conntrack --ctstate LIÉ, ÉTABLI -j ACCEPTE
 -A FORWARD -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-avec icmp-host-prohibited
 -U OUTPUT -j OUTPUT_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 ACCEPTER
 -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 --port 22 -m conntrack --ctstate NOUVEAU -j ACCEPT
 COMMETTRE
 # Terminé le Sam Apr 15 01:40:57 2017


Note 2:
J'ai installé un server web apache sur un hôte séparé auquel seul le server local a access. J'ai couru tcpdump sur le server Web écoutant sur le port 80. Quand telnet webserver 80 je capture les packages suivants. Ceci est un comportement attendu puisque la connection TCP est établie (S, S-Ack, Ack).

 [user @ webserver ~] $ sudo tcpdump -nn -vv 'port non 22 et 80' -i eth0 
 tcpdump: écoute sur eth0, type de binding EN10MB (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 écr 0, nop, wscale 7] , longueur 0
 07: 17: 30.411557 IP (tos 0x0, ttl 64, id 0, décalage 0, drapeaux [DF], proto TCP (6), longueur 60)
     web.server.80> local.server.46710: drapeaux [S.], cksum 0x8412 (incorrect -> 0x9114), seq 2651711943, ack 3018586543, gagner 28960, options [mss 1460, sackOK, TS val 37704524 écr. , 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, victoire 229, options [nop, nop, TS val 3047398 ecr 37704524], longueur 0

Lorsque je tente de me connecter au server Web à partir du server distant via le server local, tcpdump sur le server Web ne capte aucun package (même pas la synchronisation initiale) mais le server local capte le package de synchronisation envoyé au server Web. Cela me fait croire que quelque chose empêche les packages d'être envoyés au server web – peut-être une mauvaise configuration ou un pare-feu.

 [user @ local ~] $ sudo tcpdump -nn -vv 'port non 22 et 80' -i tout
 tcpdump: écoute sur n'importe quel type LINUX_SLL (Linux cuit), taille de capture 65535 octets
 02: 24: 09.135842 IP (tox 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, TSval 4780524 écrivent 0, nop, wscale 7], longueur 0

IMPORTANT: les packages ne sont pas apathés par eth0 mais essaient plutôt d'envoyer les packages au server via tun0 (ce qui échoue). Je peux le confirmer en exécutant tcpdump sur l'interface tun0:

 [user @ local ~] $ sudo tcpdump -nn -vv 'port non 22 et 80' -i tun0
 tcpdump: écoute sur tun0, type de lien RAW (Raw IP), 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 écr 0, nop, wscale 7], longueur 0

Note 3:
J'ai éteint firewalld dans l'ordinateur local et les packages de synchronisation ont été reçus par le server Web.

 [user @ local ~] $ sudo systemctl arrête firewalld
 [user @ webserver ~] $ sudo tcpdump -nn -vv 'port non 22 et 80' -i eth0
 tcpdump: écoute sur eth0, type de binding EN10MB (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, TSval 7123514 écrivent 0, nop, wscale 7], longueur 0
 08: 25: 17.391003 IP (tos 0x0, ttl 64, id 0, décalage 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, gagner 28960, options [mss 1460, sackOK, TS val 41771503 écr 7123514, nop , wscale 7], longueur 0
 08: 25: 17.391192 IP (tox 0x0, ttl 128, id 60032, décalage 0, drapeaux [aucun], proto TCP (6), longueur 40)
     10.0.2.2.50580> web.server.80: Drapeaux [R], cksum 0x7339 (correct), seq 2601927550, gain 8192, longueur 0
 08: 25: 18.393794 IP (tox 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, TSval 7124517 écrivent 0, nop, wscale 7], longueur 0
 08: 25: 18.393898 IP (tos 0x0, ttl 64, id 0, décalage 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, victoire 28960, options [mss 1460, sackOK, TS val 41772506 écr 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, gain 8192, longueur 0

Désormais clairement, l'adresse IP source doit être mise à jour pour correspondre à l'adresse IP du server local avant que le package ne soit envoyé au server Web. Comme @xin l'a suggéré, le NAT doit être configuré sur le server local.


Note # 4:
Une fois que j'essaie de me connecter au server web, je constate que le nombre de pkts pour la règle 9 augmente de 1 (voir ci-dessous).

 [user @ local ~] $ sudo iptables -nvL --line-numbers
 ..........
 Chaîne FORWARD (politique ACCEPT 0 packages, 0 octet)
 num pkts octets cible prot opt ​​in out source destination         
 1 0 0 ACCEPT all - * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATIF, ÉTABLI
 2 0 0 ACCEPT all - 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 all - * * 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 INVALIDE
 9 1 60 REJET tous - * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
 ..........
 [user @ local ~] $ sudo iptables -D FORWARD 9

Une fois que la règle 9 de la string FORWARD est supprimée (d'en haut, comme suggéré par @xin), je peux me connecter au server web.

 [user @ local ~] $ sudo iptables -nvL --line-numbers
 ..........
 Chaîne FORWARD (politique ACCEPT 1 packages, 60 octets)
 num pkts octets cible prot opt ​​in out source destination         
 1 12 5857 ACCEPT tous - * * 0.0.0.0/0 0.0.0.0/0 ctstate LIÉS, ÉTABLIS
 2 0 0 ACCEPT all - lo * 0.0.0.0/0 0.0.0.0/0           
 3 2 120 FORWARD_direct all - * * 0.0.0.0/0 0.0.0.0/0           
 4 2 120 FORWARD_IN_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0           
 5 2 120 FORWARD_IN_ZONES tous - * * 0.0.0.0/0 0.0.0.0/0           
 6 2 120 FORWARD_OUT_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0           
 7 2 120 FORWARD_OUT_ZONES toutes - * * 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 INVALIDE
 ..........

L'adresse source des packages doit être remplacée par une adresse de la machine locale afin que les réponses puissent être reçues par la machine locale, sinon il n'y a pas (bonne) raison d'envoyer ces packages aux routeurs suivants. iptables MASQUERADE et SNAT sont utiles pour changer l'adresse source de ces packages:

 [user@local ~]$ iptables -t nat -A POSTROUTING -s 10.0.2.2/32 ! -d 10.0.2.1/30 -j MASQUERADE -o eth0