Hier ist das Problem, das ich zu lösen versuche. Es gibt einen Server („Remote-System“), auf den ich mich von meinem lokalen Computer aus per SSH einloggen kann, aber dieses Remote-System hat keine Internetverbindung. Ich möchte dem Remote-System über meinen lokalen Computer mit einem SSH-basierten VPN Zugriff auf das Internet gewähren. Wie erreiche ich das? Ich habe Folgendes versucht, was teilweise zu funktionieren scheint. Mit „teilweise funktionieren“ meine ich, dass Verbindungspakete (Sync-Pakete) an meinen lokalen Computer gesendet werden, aber keine Verbindung zum Internet hergestellt werden kann. Ich verwende tcpdump, um Pakete auf dem lokalen Computer zu erfassen. Auf dem lokalen Computer und dem Remote-System läuft CentOS 7.
Die Einrichtung- Hinweis: Die folgenden Befehle werden der Reihe nach ausgeführt. Die user@remote-Befehle werden auf dem Remote-Server ausgeführt und die user@local-Befehle auf dem lokalen Computer.
[Benutzer@Remote ~]$ IP-Adresse anzeigen
1: lo: mtu 65536 qdisc noqueue status UNBEKANNT
Link/Loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 Bereich Host lo
valid_lft für immer preferred_lft für immer
inet6 ::1/128 Bereich Host
valid_lft für immer preferred_lft für immer
2: eth0: mtu 1500 qdisc pfifo_fast Status UP qlen 1000
Link/Ä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 Bereich global dynamisch eth0
valid_lft 1785 Sek. bevorzugt_lft 1785 Sek.
inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 Bereich global noprefixroute dynamisch
valid_lft 2591987 Sek. bevorzugt_lft 604787 Sek.
inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 Bereichslink
valid_lft für immer preferred_lft für immer
[Benutzer@lokal ~]$ IP-Adresse anzeigen
1: lo: mtu 65536 qdisc noqueue status UNBEKANNT
Link/Loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 Bereich Host lo
valid_lft für immer preferred_lft für immer
inet6 ::1/128 Bereich Host
valid_lft für immer preferred_lft für immer
2: eth0: mtu 1500 qdisc pfifo_fast Status UP qlen 1000
Link/Ä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 Bereich global dynamisch eth0
valid_lft 1785 Sek. bevorzugt_lft 1785 Sek.
inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 Bereich global noprefixroute dynamisch
valid_lft 2591987 Sek. bevorzugt_lft 604787 Sek.
inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 Bereichslink
valid_lft für immer preferred_lft für immer
Erstellen Sie die tun0 Schnittstelle auf demFernbedienungSystem.
[Benutzer@Remote ~]$ sudo ip tuntap add tun0 mode tun
[Benutzer@Remote ~]$ IP-Adresse anzeigen
1: lo: mtu 65536 qdisc noqueue status UNBEKANNT
Link/Loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 Bereich Host lo
valid_lft für immer preferred_lft für immer
inet6 ::1/128 Bereich Host
valid_lft für immer preferred_lft für immer
2: eth0: mtu 1500 qdisc pfifo_fast Status UP qlen 1000
Link/Ä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 Bereich global dynamisch eth0
valid_lft 1785 Sek. bevorzugt_lft 1785 Sek.
inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 Bereich global noprefixroute dynamisch
valid_lft 2591987 Sek. bevorzugt_lft 604787 Sek.
inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 Bereichslink
valid_lft für immer preferred_lft für immer
3: tun0: mtu 1500 qdisc Noop-Status DOWN qlen 500
Link/keine
Erstellen Sie die tun0 Schnittstelle auf demlokalSystem.
[Benutzer@local ~]$ sudo ip tuntap add tun0 mode tun
[Benutzer@lokal ~]$ IP-Adresse anzeigen
1: lo: mtu 65536 qdisc noqueue status UNBEKANNT
Link/Loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 Bereich Host lo
valid_lft für immer preferred_lft für immer
inet6 ::1/128 Bereich Host
valid_lft für immer preferred_lft für immer
2: eth0: mtu 1500 qdisc pfifo_fast Status UP qlen 1000
Link/Ä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 Bereich global dynamisch eth0
valid_lft 1785 Sek. bevorzugt_lft 1785 Sek.
inet6 EEEE:FFFF:GGGG:HHHH:IIII:JJJJ:KKKK:LLLL/64 Bereich global noprefixroute dynamisch
valid_lft 2591987 Sek. bevorzugt_lft 604787 Sek.
inet6 ABCD::IIII:JJJJ:KKKK:LLLL/64 Bereichslink
valid_lft für immer preferred_lft für immer
3: tun0: mtu 1500 qdisc Noop-Status DOWN qlen 500
Link/keine
Weisen Sie tun0 eine IP-Adresse zu und starten Sie es:
[Benutzer@local ~]$ sudo ip addr add 10.0.2.1/30 dev tun0
[Benutzer@local ~]$ sudo ip link set dev tun0 up
[Benutzer@lokal ~]$ IP-Adresse show tun0
3: tun0: mtu 1500 qdisc pfifo_fast Status DOWN qlen 500
Link/keine
inet 10.0.2.1/30 Bereich global tun0
valid_lft für immer preferred_lft für immer
[Benutzer@Remote ~]$ sudo ip addr add 10.0.2.2/30 dev tun0
[Benutzer@Remote ~]$ sudo ip link set dev tun0 up
[Benutzer@Remote ~]$ IP-Adresse show tun0
3: tun0: mtu 1500 qdisc pfifo_fast Status DOWN qlen 500
Link/keine
inet 10.0.2.2/30 Bereich global tun0
valid_lft für immer preferred_lft für immer
Ändern Sie sshd_config sowohl auf dem Remote- als auch auf dem lokalen System, um Tunneling zu aktivieren:
[Benutzer@Remote ~]$ sudo grep PermitTunnel /etc/ssh/sshd_config PermitTunnel Punkt-zu-Punkt
[Benutzer@local ~]$ sudo grep PermitTunnel /etc/ssh/sshd_config PermitTunnel Punkt-zu-Punkt
Erstellen Sie den SSH-Tunnel:
[Benutzer@lokal ~]$ sudo ssh -f -w0:0 root@remote true root@remotes Passwort: [Benutzer@lokal ~]$ ps aux | grep root@remote root 1851 0,0 0,0 76112 1348 ? Ss 23:12 0:00 ssh -f -w0:0 root@remote true
Testen Sie den Ping auf beiden Servern mit den neuen IP-Adressen:
[Benutzer@lokal ~]$ ping 10.0.2.2 -c 2 PING 10.0.2.2 (10.0.2.2) 56(84) Bytes Daten. 64 Bytes von 10.0.2.2: icmp_seq=1 ttl=64 Zeit=1,68 ms 64 Bytes von 10.0.2.2: icmp_seq=2 ttl=64 Zeit=0,861 ms --- 10.0.2.2 Ping-Statistiken --- 2 Pakete gesendet, 2 empfangen, 0 % Paketverlust, Zeit 1002 ms RTT min./Durchschnitt/max./mdev = 0,861/1,274/1,688/0,415 ms
[Benutzer@Remote ~]$ ping 10.0.2.1 -c 2 PING 10.0.2.1 (10.0.2.1) 56(84) Bytes Daten. 64 Bytes von 10.0.2.1: icmp_seq=1 ttl=64 Zeit=0,589 ms 64 Bytes von 10.0.2.1: icmp_seq=2 ttl=64 Zeit=0,889 ms --- 10.0.2.1 Ping-Statistiken --- 2 Pakete gesendet, 2 empfangen, 0 % Paketverlust, Zeit 1000 ms RTT min./avg./max./mdev. = 0,589/0,739/0,889/0,150 ms
[Benutzer@Remote ~]$ Route Kernel-IP-Routing-Tabelle Ziel-Gateway Genmask Flags Metrik Ref Verwendung Iface Standard-Gateway 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 [Benutzer@Remote ~]$ IP-Route anzeigen Standardmäßig über AAA.BBB.CCC.1 dev eth0 proto statische Metrik 100 10.0.2.0/30 dev tun0 proto Kernel Bereich Link src 10.0.2.2 AAA.BBB.CCC.0/24 dev eth0 proto Kernel Bereich Link src AAA.BBB.CCC.31 Metrik 100
Holen Sie sich Google-IP-Adressen:
[Benutzer@local ~]$ nslookup google.com Server: Server Adresse: Server#53 Nicht verbindliche Antwort: Name: google.com Adresse: 173.194.219.101 Name: google.com Adresse: 173.194.219.100 Name: google.com Adresse: 173.194.219.113 Name: google.com Adresse: 173.194.219.102 Name: google.com Adresse: 173.194.219.139 Name: google.com Adresse: 173.194.219.138
WICHTIG: Ich habe den obigen Befehl zu einem anderen Zeitpunkt ausgeführt und ein anderes Ergebnis erhalten. Gehen Sie nicht davon aus, dass Ihre Antwort mit meiner für nslookup oben übereinstimmt.
Da alle IP-Adressen von Google mit 173.194.219 beginnen, leiten wir alle diese IP-Adressen über den lokalen Computer.
[Benutzer@Remote ~]$ sudo ip route add 173.194.219.0/24 dev tun0 [Benutzer@Remote ~]$ Route Kernel-IP-Routing-Tabelle Ziel-Gateway Genmask Flags Metrik Ref Verwendung Iface Standard-Gateway 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 [Benutzer@Remote ~]$ IP-Route anzeigen Standardmäßig über AAA.BBB.CCC.1 dev eth0 proto statische Metrik 100 10.0.2.0/30 dev tun0 proto Kernel Bereich Link src 10.0.2.2 AAA.BBB.CCC.0/24 dev eth0 proto Kernel Bereich Link src AAA.BBB.CCC.31 Metrik 100 173.194.219.0/24 dev tun0 Bereichslink
Aktivieren Sie die IP-Weiterleitung:
[Benutzer@local ~]$ grep ip_forward /etc/sysctl.conf net.ipv4.ip_forward = 1 [Benutzer@local ~]$ sudo service network restart Netzwerk neu starten (über systemctl): [ OK ]
Richten Sie die Paketerfassung auf dem lokalen Computer mithilfe von tcpdump ein:
[Benutzer@local ~]$ sudo tcpdump -nn -vv 'Port nicht 22' -i any tcpdump: lauscht auf jedem, Link-Typ LINUX_SLL (Linux-gekocht), Erfassungsgröße 65535 Bytes
Versuchen Sie, vom Remote-Server aus eine Verbindung zu Google herzustellen.
[Benutzer@Remote ~]$ openssl s_client -connect google.com:443 Socket: Keine Route zum Host verbinden:errno=113
Sobald der OpenSSL-Befehl auf dem Remote-Server ausgeführt wird, erfasst der TCPdump einige Pakete:
10.0.2.2.52768 > 173.194.219.102.443: Flags [S], cksum 0x8702 (korrekt), seq 994650730, win 29200, Optionen [mss 1460,sackOK,TS val 7701438 ecr 0,nop,wscale 7], Länge 0
00:49:33.247753 IP (tos 0x0, ttl 64, id 46037, offset 0, flags [DF], proto TCP (6), länge 60)
10.0.2.2.48774 > 173.194.219.100.443: Flags [S], cksum 0x47a7 (korrekt), seq 2218733674, win 29200, Optionen [mss 1460,sackOK,TS val 7701439 ecr 0,nop,wscale 7], Länge 0
00:49:33.247883 IP (tos 0xc0, ttl 64, ID 9538, Offset 0, Flags [keine], Proto ICMP (1), Länge 88)
10.0.2.1 > 10.0.2.2: ICMP-Host 173.194.219.100 nicht erreichbar – Administrator verboten, Länge 68
IP (tos 0x0, ttl 63, ID 46037, Offset 0, Flags [DF], Proto TCP (6), Länge 60)
10.0.2.2.48774 > 173.194.219.100.443: Flags [S], cksum 0x47a7 (korrekt), seq 2218733674, win 29200, Optionen [mss 1460,sackOK,TS val 7701439 ecr 0,nop,wscale 7], Länge 0
00:49:33.253068 IP (tos 0x0, ttl 64, id 26282, offset 0, flags [DF], proto TCP (6), länge 60)
10.0.2.2.51312 > 173.194.219.101.443: Flags [S], cksum 0x6ff8 (korrekt), seq 2634016105, win 29200, Optionen [mss 1460,sackOK,TS val 7701443 ecr 0,nop,wscale 7], Länge 0
00:49:33.254771 IP (tos 0xc0, ttl 64, ID 9539, Offset 0, Flags [keine], Proto ICMP (1), Länge 88)
10.0.2.1 > 10.0.2.2: ICMP-Host 173.194.219.101 nicht erreichbar – Administrator verboten, Länge 68
IP (tos 0x0, ttl 63, id 26282, offset 0, flags [DF], proto TCP (6), länge 60)
10.0.2.2.51312 > 173.194.219.101.443: Flags [S], cksum 0x6ff8 (korrekt), seq 2634016105, win 29200, Optionen [mss 1460,sackOK,TS val 7701443 ecr 0,nop,wscale 7], Länge 0
00:49:33.258805 IP (tos 0x0, ttl 64, id 9293, offset 0, flags [DF], proto TCP (6), länge 60)
10.0.2.2.33686 > 173.194.219.139.443: Flags [S], cksum 0x542b (korrekt), seq 995927943, win 29200, Optionen [mss 1460,sackOK,TS val 7701450 ecr 0,nop,wscale 7], Länge 0
00:49:33.258845 IP (tos 0xc0, ttl 64, id 9540, offset 0, flags [keine], proto ICMP (1), länge 88)
10.0.2.1 > 10.0.2.2: ICMP-Host 173.194.219.139 nicht erreichbar – Administrator verboten, Länge 68
IP (tos 0x0, ttl 63, ID 9293, Offset 0, Flags [DF], Proto TCP (6), Länge 60)
10.0.2.2.33686 > 173.194.219.139.443: Flags [S], cksum 0x542b (korrekt), seq 995927943, win 29200, Optionen [mss 1460,sackOK,TS val 7701450 ecr 0,nop,wscale 7], Länge 0
^C
13 Pakete erfasst
13 Pakete vom Filter empfangen
0 Pakete vom Kernel verworfen
Die mit tcpdump erfassten Pakete lassen darauf schließen, dass versucht wird, die Verbindung herzustellen (Sync-Pakete werden gesendet), aber nichts empfangen wird. Außerdem gibt es eine Meldung 10.0.2.1 > 10.0.2.2: ICMP host 173.194.219.139 unreachable - admin prohibited, length 68, die auf ein Problem hinzuweisen scheint.
Gibt es Vorschläge, wie man dieses Problem umgehen kann? Müssen iptable-Regeln hinzugefügt werden? Gibt es Firewall-Probleme (Firewall-D?).
Anmerkung 1
Ausgabe von iptables-save:
[Benutzer@local ~]$ sudo iptables -t nat -A POSTROUTING -s 10.0.2.2/32 ! -d 10.0.2.1/30 -j MASQUERADE -o eth0 [Benutzer@local ~]$ sudo iptables-save # Generiert von iptables-save v1.4.21 am Samstag, 15. April 2017, 01:40:57 Uhr *nat :PRE-ROUTING AKZEPTIEREN [35:8926] :EINGABE AKZEPTIEREN [1:84] :AUSGABE AKZEPTIEREN [6:439] :POSTROUTING AKZEPTIEREN [6:439] :OUTPUT_direkt - [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 Vorrouting -j Vorrouting_direkt -A VORROUTING -j VORROUTING_ZONENQUELLE -A VORROUTING -j VORROUTINGZONEN -A AUSGABE -j AUSGABE_direkt -A POSTROUTING -j POSTROUTING_direkt -A POSTROUTING -j POSTROUTING_ZONES_SOURCE -A POSTROUTING -j POSTROUTING_ZONEN -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 VORROUTING_ZONEN -i eth0 -g VOR_öffentlich -A VORROUTING_ZONEN -g VOR_öffentlich -A VOR_öffentlich -j VOR_öffentlich_log -A PRE_öffentlich -j PRE_öffentlich_verweigern -A VOR_öffentlich -j VOR_öffentlich_zulassen BEGEHEN # Abgeschlossen am Samstag, 15. April 2017, 01:40:57 Uhr # Generiert von iptables-save v1.4.21 am Samstag, 15. April 2017, 01:40:57 Uhr *Mangel :PRE-ROUTING AKZEPTIEREN [169:18687] :EINGABE AKZEPTIEREN [144:11583] :Weiterleiten Annehmen [0:0] :AUSGABE AKZEPTIEREN [80:8149] :POSTROUTING AKZEPTIEREN [80:8149] :FORWARD_direkt - [0:0] :INPUT_direct - [0:0] :OUTPUT_direkt - [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 Vorrouting -j Vorrouting_direkt -A VORROUTING -j VORROUTING_ZONENQUELLE -A VORROUTING -j VORROUTINGZONEN -A EINGABE -j EINGABE_direkt -A VORWÄRTS -j VORWÄRTS_direkt -A AUSGABE -j AUSGABE_direkt -A POSTROUTING -j POSTROUTING_direkt -A VORROUTING_ZONEN -i eth0 -g VOR_öffentlich -A VORROUTING_ZONEN -g VOR_öffentlich -A VOR_öffentlich -j VOR_öffentlich_log -A PRE_öffentlich -j PRE_öffentlich_verweigern -A VOR_öffentlich -j VOR_öffentlich_zulassen BEGEHEN # Abgeschlossen am Samstag, 15. April 2017, 01:40:57 Uhr # Generiert von iptables-save v1.4.21 am Samstag, 15. April 2017, 01:40:57 Uhr *Sicherheit :EINGABE AKZEPTIEREN [2197:163931] :Weiterleiten Annehmen [0:0] :AUSGABE AKZEPTIEREN [1229:185742] :FORWARD_direkt - [0:0] :INPUT_direct - [0:0] :OUTPUT_direkt - [0:0] -A EINGABE -j EINGABE_direkt -A VORWÄRTS -j VORWÄRTS_direkt -A AUSGABE -j AUSGABE_direkt BEGEHEN # Abgeschlossen am Samstag, 15. April 2017, 01:40:57 Uhr # Generiert von iptables-save v1.4.21 am Samstag, 15. April 2017, 01:40:57 Uhr *roh :PREROUTING AKZEPTIEREN [2362:184437] :AUSGABE AKZEPTIEREN [1229:185742] :OUTPUT_direkt - [0:0] :PREROUTING_direct - [0:0] -A Vorrouting -j Vorrouting_direkt -A AUSGABE -j AUSGABE_direkt BEGEHEN # Abgeschlossen am Samstag, 15. April 2017, 01:40:57 Uhr # Generiert von iptables-save v1.4.21 am Samstag, 15. April 2017, 01:40:57 Uhr *Filter :EINGABE AKZEPTIEREN [0:0] :Weiterleiten Annehmen [0:0] :AUSGABE AKZEPTIEREN [80:8149] :VORWÄRTS_IN_ZONEN - [0:0] :VORWÄRTS_IN_ZONEN_QUELLE - [0:0] :VORWÄRTS_AUS_ZONEN - [0:0] :FORWARD_OUT_ZONES_SOURCE - [0:0] :FORWARD_direkt - [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_direkt - [0:0] -A INPUT -m conntrack --ctstate VERWANDTE, ETABLIERTE -j AKZEPTIEREN -A EINGABE -i lo -j AKZEPTIEREN -A EINGABE -j EINGABE_direkt -A EINGABE -j EINGABEZONENQUELLE -A EINGABE -j EINGABEZONEN -A INPUT -m conntrack --ctstate UNZULÄSSIG -j DROP -A INPUT -j REJECT --reject-with icmp-host-prohibited -A WEITER -m conntrack --ctstate VERWANDTE, ETABLIERTE -j AKZEPTIEREN -A WEITER -i lo -j AKZEPTIEREN -A VORWÄRTS -j VORWÄRTS_direkt -A WEITER -j WEITER_IN_ZONENQUELLE -A WEITER -j WEITER_IN_ZONEN -A WEITER -j WEITER_AUS_ZONENQUELLE -A VORWÄRTS -j VORWÄRTS_AUS_ZONEN -A WEITER -m conntrack --ctstate UNZULÄSSIG -j DROP -A WEITER -j ABLEHNEN --reject-with icmp-host-prohibited -A AUSGABE -j AUSGABE_direkt -A FORWARD_IN_ZONES -i eth0 -g FWDI_public -A WEITERLEITUNG IN ZONEN -g FWDI_public -A FORWARD_OUT_ZONES -o eth0 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FWDI_öffentlich -j FWDI_öffentliches_log -A FWDI_public -j FWDI_public_deny -A FWDI_öffentlich -j FWDI_öffentlich_zulassen -A FWDI_public -p icmp -j AKZEPTIEREN -A FWDO_öffentlich -j FWDO_öffentliches_log -A FWDO_public -j FWDO_public_deny -A FWDO_öffentlich -j FWDO_öffentlich_zulassen -A EINGABEZONEN -i eth0 -g EINGABE_Öffentlich -A EINGABEZONEN -g EINGABE_Öffentlich -A IN_öffentlich -j IN_öffentliches_log -A IN_public -j IN_public_deny -A IN_öffentlich -j IN_öffentlich_zulassen -A IN_public -p icmp -j AKZEPTIEREN -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEU -j AKZEPTIEREN BEGEHEN # Abgeschlossen am Samstag, 15. April 2017, 01:40:57 Uhr
Anmerkung 2:
Ich habe einen Apache-Webserver auf einem separaten Host eingerichtet, auf den nur der lokale Server Zugriff hat. Ich habe tcpdump auf dem Webserver ausgeführt, der auf Port 80 lauscht. Beim Ausführen
telnet webserver 80erfasse ich die folgenden Pakete. Dies ist das erwartete Verhalten, da die TCP-Verbindung hergestellt ist (S, S-Ack, Ack).
[Benutzer@Webserver ~]$ sudo tcpdump -nn -vv 'Port nicht 22 und 80' -i eth0
tcpdump: lauscht auf eth0, Link-Typ EN10MB (Ethernet), Erfassungsgröße 65535 Bytes
07:17:30.411474 IP (tos 0x10, ttl 64, id 34376, offset 0, flags [DF], proto TCP (6), länge 60)
local.server.46710 > web.server.80: Flags [S], cksum 0x8412 (falsch -> 0x6d96), seq 3018586542, win 29200, Optionen [mss 1460,sackOK,TS val 3047398 ecr 0,nop,wscale 7], Länge 0
07:17:30.411557 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), länge 60)
web.server.80 > local.server.46710: Flags [S.], cksum 0x8412 (falsch -> 0x9114), seq 2651711943, ack 3018586543, win 28960, Optionen [mss 1460,sackOK,TS val 37704524 ecr 3047398,nop,wscale 7], Länge 0
07:17:30.411725 IP (tos 0x10, ttl 64, id 34377, offset 0, flags [DF], proto TCP (6), länge 52)
local.server.46710 > web.server.80: Flags [.], cksum 0x840a (falsch -> 0x301c), seq 1, ack 1, win 229, Optionen [nop,nop,TS val 3047398 ecr 37704524], Länge 0
Wenn ich versuche, vom Remote-Server über den lokalen Server eine Verbindung zum Webserver herzustellen, erfasst TCPdump auf dem Webserver keine Pakete (nicht einmal die anfängliche Synchronisierung), aber der lokale Server erfasst das an den Webserver gesendete Synchronisierungspaket (siehe unten). Dies lässt mich glauben, dass etwas das Senden der Pakete an den Webserver verhindert - möglicherweise eine Fehlkonfiguration oder Firewall.
[user@local ~]$ sudo tcpdump -nn -vv 'Port nicht 22 und 80' -i any
tcpdump: lauscht auf jedem, Link-Typ LINUX_SLL (Linux-gekocht), Erfassungsgröße 65535 Bytes
02:24:09.135842 IP (tos 0x10, ttl 64, id 38062, offset 0, flags [DF], proto TCP (6), länge 60)
10.0.2.2.50558 > web.server.80: Flags [S], cksum 0x668d (korrekt), seq 69756226, win 29200, Optionen [mss 1460,sackOK,TS val 4780524 ecr 0,nop,wscale 7], Länge 0
WICHTIG:die Pakete werden nicht über eth0 geroutet, sondern es wird versucht, die Pakete über tun0 an den Webserver zu senden (was fehlschlägt). Ich kann dies bestätigen, indem ich tcpdump auf der tun0-Schnittstelle ausführe:
[Benutzer@lokal ~]$ sudo tcpdump -nn -vv 'Port nicht 22 und 80' -i tun0
tcpdump: lauscht auf tun0, Link-Typ RAW (Raw IP), Erfassungsgröße 65535 Bytes
02:28:10.295972 IP (tos 0x10, ttl 64, id 46976, offset 0, flags [DF], proto TCP (6), länge 60)
10.0.2.2.50560 > webserver.80: Flags [S], cksum 0xd560 (korrekt), seq 605366388, win 29200, Optionen [mss 1460,sackOK,TS val 5021684 ecr 0,nop,wscale 7], Länge 0
Notiz 3:
Ich habe die Firewall auf dem lokalen Computer ausgeschaltet und der Webserver hat Synchronisierungspakete empfangen.
[Benutzer@local ~]$ sudo systemctl stop firewalld
[Benutzer@Webserver ~]$ sudo tcpdump -nn -vv 'Port nicht 22 und 80' -i eth0
tcpdump: lauscht auf eth0, Link-Typ EN10MB (Ethernet), Erfassungsgröße 65535 Bytes
08:25:17.390912 IP (tos 0x10, ttl 63, id 61767, offset 0, flags [DF], proto TCP (6), länge 60)
10.0.2.2.50580 > web.server.80: Flags [S], cksum 0x30dc (korrekt), seq 2601927549, win 29200, Optionen [mss 1460,sackOK,TS val 7123514 ecr 0,nop,wscale 7], Länge 0
08:25:17.391003 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), länge 60)
web.server.80 > 10.0.2.2.50580: Flags [S.], cksum 0x4e23 (falsch -> 0xa316), seq 959115533, ack 2601927550, win 28960, Optionen [mss 1460,sackOK,TS val 41771503 ecr 7123514,nop,wscale 7], Länge 0
08:25:17.391192 IP (tos 0x0, ttl 128, ID 60032, Offset 0, Flags [keine], Proto TCP (6), Länge 40)
10.0.2.2.50580 > web.server.80: Flags [R], cksum 0x7339 (korrekt), seq 2601927550, win 8192, Länge 0
08:25:18.393794 IP (tos 0x10, ttl 63, id 61768, offset 0, flags [DF], proto TCP (6), länge 60)
10.0.2.2.50580 > web.server.80: Flags [S], cksum 0x2cf1 (korrekt), seq 2601927549, win 29200, Optionen [mss 1460,sackOK,TS val 7124517 ecr 0,nop,wscale 7], Länge 0
08:25:18.393898 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), länge 60)
web.server.80 > 10.0.2.2.50580: Flags [S.], cksum 0x4e23 (falsch -> 0x7e71), seq 974785773, ack 2601927550, win 28960, Optionen [mss 1460,sackOK,TS val 41772506 ecr 7124517,nop,wscale 7], Länge 0
08:25:18.394003 IP (tos 0x0, ttl 128, ID 60033, Offset 0, Flags [keine], Proto TCP (6), Länge 40)
10.0.2.2.50580 > web.server.80: Flags [R], cksum 0x566a (korrekt), seq 2601927550, win 8192, Länge 0
Jetzt muss die Quell-IP natürlich aktualisiert werden, damit sie mit der IP-Adresse des lokalen Servers übereinstimmt, bevor das Paket an den Webserver gesendet wird. Wie @xin vorgeschlagen hat, muss NAT auf dem lokalen Server eingerichtet werden.
Hinweis Nr. 4:
Wenn ich versuche, eine Verbindung zum Webserver herzustellen, kann ich sehen, dass die Paketanzahl für Regel 9 um 1 steigt (siehe unten).
[Benutzer@local ~]$ sudo iptables -nvL --line-numbers .......... Chain FORWARD (Richtlinie ACCEPT 0 Pakete, 0 Bytes) Anzahl Pakete Bytes Ziel Schutz Opt In Out Quelle Ziel 1 0 0 alles akzeptieren -- * * 0.0.0.0/0 0.0.0.0/0 ctstate VERWANDTE, ETABLIERTE 2 0 0 alles akzeptieren -- lo * 0.0.0.0/0 0.0.0.0/0 3 1 60 FORWARD_direct alle -- * * 0.0.0.0/0 0.0.0.0/0 4 1 60 FORWARD_IN_ZONES_SOURCE alle -- * * 0.0.0.0/0 0.0.0.0/0 5 1 60 FORWARD_IN_ZONES alle -- * * 0.0.0.0/0 0.0.0.0/0 6 1 60 FORWARD_OUT_ZONES_SOURCE alle -- * * 0.0.0.0/0 0.0.0.0/0 7 1 60 FORWARD_OUT_ZONES alle -- * * 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP alle -- * * 0.0.0.0/0 0.0.0.0/0 ctstate UNGÜLTIG 9 1 60 ALLE ABLEHNEN -- * * 0.0.0.0/0 0.0.0.0/0 Ablehnung mit ICMP-Host verboten .......... [Benutzer@local ~]$ sudo iptables -D VORWÄRTS 9
Sobald Regel 9 aus der FORWARD-Kette gelöscht ist (von oben, wie @xin vorgeschlagen hat), kann ich eine Verbindung zum Webserver herstellen.
[Benutzer@local ~]$ sudo iptables -nvL --line-numbers .......... Chain FORWARD (Richtlinie ACCEPT 1 Pakete, 60 Bytes) Anzahl Pakete Bytes Ziel Schutz Opt In Out Quelle Ziel 1 12 5857 alles akzeptieren -- * * 0.0.0.0/0 0.0.0.0/0 ctstate VERWANDTE, ETABLIERTE 2 0 0 alles akzeptieren -- lo * 0.0.0.0/0 0.0.0.0/0 3 2 120 FORWARD_direct alle -- * * 0.0.0.0/0 0.0.0.0/0 4 2 120 FORWARD_IN_ZONES_SOURCE alle -- * * 0.0.0.0/0 0.0.0.0/0 5 2 120 FORWARD_IN_ZONES alle -- * * 0.0.0.0/0 0.0.0.0/0 6 2 120 FORWARD_OUT_ZONES_SOURCE alle -- * * 0.0.0.0/0 0.0.0.0/0 7 2 120 FORWARD_OUT_ZONES alle -- * * 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP alle -- * * 0.0.0.0/0 0.0.0.0/0 ctstate UNGÜLTIG ..........
Antwort1
Die Quelladresse der Pakete sollte durch eine Adresse des lokalen Rechners ersetzt werden, damit die Antworten vom lokalen Rechner empfangen werden können. Andernfalls gibt es keinen (guten) Grund, diese Pakete an die nächsten Router zu senden, da die Antworten ohnehin nicht abgefangen werden können. iptables MASQUERADEund SNATsind nützlich, um die Quelladresse dieser Pakete zu ändern:
[user@local ~]$ iptables -t nat -A POSTROUTING -s 10.0.2.2/32 ! -d 10.0.2.1/30 -j MASQUERADE -o eth0