Hier ist das Problem, das ich zu lösen versuche. Es gibt einen Server ("Remote-System"), auf den ich von meinem lokalen Computer aus ssh kann, aber dieses Remote-System verfügt nicht über eine Internetverbindung. Ich möchte dem Remote-System über meinen lokalen Computer mithilfe von SSH-basiertem VPN Zugriff auf das Internet gewähren. Wie schaffe ich das? Ich habe folgendes versucht, was teilweise zu funktionieren scheint. Was ich unter "teilweise funktionieren" verstehe, ist, dass Verbindungspakete (Synchronisierungspakete) an meinen lokalen Computer gesendet werden, aber keine Verbindung zum Internet herstellen können. Ich verwende tcpdump, um Pakete auf einem lokalen Computer zu erfassen. Auf dem lokalen Computer und dem Remote-System wird Centos 7 ausgeführt.
Das Setup - Hinweis: Die folgenden Befehle werden der Reihe nach ausgeführt. Die Befehle user @ remote werden auf dem Remote-Server und die Befehle user @ local auf dem lokalen Computer ausgeführt.
[user @ remote ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNBEKANNT
Link / Loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valid_lft für immer bevorzugt_lft für immer
inet6 :: 1/128 Scope Host
valid_lft für immer bevorzugt_lft für immer
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
Link / Äther AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope global dynamic eth0
valid_lft 1785sec bevorzugt_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64-Bereich globale Noprefixroute-Dynamik
valid_lft 2591987sec bevorzugt_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64-Bereichsverknüpfung
valid_lft für immer bevorzugt_lft für immer
[user @ local ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNBEKANNT
Link / Loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valid_lft für immer bevorzugt_lft für immer
inet6 :: 1/128 Scope Host
valid_lft für immer bevorzugt_lft für immer
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
Link / Äther AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope global dynamic eth0
valid_lft 1785sec bevorzugt_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64-Bereich globale Noprefixroute-Dynamik
valid_lft 2591987sec bevorzugt_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64-Bereichsverknüpfung
valid_lft für immer bevorzugt_lft für immer
Erstellen Sie die tun0-Schnittstelle auf dem Remote- System.
[user @ remote ~] $ sudo ip tuntap add tun0 mode tun
[user @ remote ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNBEKANNT
Link / Loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valid_lft für immer bevorzugt_lft für immer
inet6 :: 1/128 Scope Host
valid_lft für immer bevorzugt_lft für immer
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
Link / Äther AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope global dynamic eth0
valid_lft 1785sec bevorzugt_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64-Bereich globale Noprefixroute-Dynamik
valid_lft 2591987sec bevorzugt_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64-Bereichsverknüpfung
valid_lft für immer bevorzugt_lft für immer
3: tun0: mtu 1500 qdisc noop state DOWN qlen 500
Link / keine
Erstellen Sie die tun0-Schnittstelle auf dem lokalen System.
[user @ local ~] $ sudo ip tuntap Tun0-Modus hinzufügen tun
[user @ local ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNBEKANNT
Link / Loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valid_lft für immer bevorzugt_lft für immer
inet6 :: 1/128 Scope Host
valid_lft für immer bevorzugt_lft für immer
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
Link / Äther AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope global dynamic eth0
valid_lft 1785sec bevorzugt_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64-Bereich globale Noprefixroute-Dynamik
valid_lft 2591987sec bevorzugt_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64-Bereichsverknüpfung
valid_lft für immer bevorzugt_lft für immer
3: tun0: mtu 1500 qdisc noop state DOWN qlen 500
Link / keine
Weisen Sie tun0 eine IP-Adresse zu und rufen Sie sie auf:
[user @ local ~] $ sudo ip addr add 10.0.2.1/30 dev tun0
[user @ local ~] $ sudo ip link set dev tun0 up
[user @ local ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast state DOWN qlen 500
Link / keine
inet 10.0.2.1/30 scope global tun0
valid_lft für immer bevorzugt_lft für immer
[user @ remote ~] $ sudo ip addr add 10.0.2.2/30 dev tun0
[user @ remote ~] $ sudo ip link set dev tun0 up
[user @ remote ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast state DOWN qlen 500
Link / keine
inet 10.0.2.2/30 scope global tun0
valid_lft für immer bevorzugt_lft für immer
Ändern Sie sshd_config sowohl auf dem Remote- als auch auf dem lokalen System, um das Tunneln zu aktivieren:
[user @ remote ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config PermitTunnel Punkt zu Punkt
[user @ local ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config PermitTunnel Punkt zu Punkt
Erstellen Sie den SSH-Tunnel:
[user @ local ~] $ sudo ssh -f -w0: 0 root @ remote true root @ remote Passwort: [user @ local ~] $ ps aux | grep root @ remote Wurzel 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:
[user @ local ~] $ ping 10.0.2.2 -c 2 PING 10.0.2.2 (10.0.2.2) 56 (84) Datenbytes. 64 Bytes ab 10.0.2.2: icmp_seq = 1 ttl = 64 Zeit = 1,68 ms 64 Bytes ab 10.0.2.2: icmp_seq = 2 ttl = 64 time = 0,861 ms --- 10.0.2.2 Ping-Statistiken --- 2 gesendete Pakete, 2 empfangene, 0% Paketverlust, Zeit 1002 ms rtt min / avg / 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) Datenbytes. 64 Bytes ab 10.0.2.1: icmp_seq = 1 ttl = 64 Zeit = 0,589 ms 64 Bytes ab 10.0.2.1: icmp_seq = 2 ttl = 64 time = 0,889 ms --- 10.0.2.1 Ping-Statistiken --- 2 gesendete Pakete, 2 empfangene, 0% Paketverlust, Zeit 1000 ms rtt min / avg / max / mdev = 0,589 / 0,739 / 0,889 / 0,150 ms
[user @ remote ~] $ route Kernel-IP-Routing-Tabelle Destination Gateway Genmask Flags Metric Ref Verwenden Sie 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 [user @ remote ~] $ ip route show Standard über AAA.BBB.CCC.1 dev eth0 protostatische Metrik 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 metrisch 100
Holen Sie sich Google IP-Adressen:
[user @ local ~] $ nslookup google.com Server: Server Adresse: Server # 53 Nicht maßgebliche 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 identisch ist.
Da alle IP-Adressen von Google mit 173.194.219 beginnen, können Sie alle diese IP-Adressen über den lokalen Computer weiterleiten.
[user @ remote ~] $ sudo ip route add 173.194.219.0/24 dev tun0 [user @ remote ~] $ route Kernel-IP-Routing-Tabelle Destination Gateway Genmask Flags Metric Ref Verwenden Sie 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 [user @ remote ~] $ ip route show Standard über AAA.BBB.CCC.1 dev eth0 protostatische Metrik 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 metrisch 100 173.194.219.0/24 dev tun0 scope link
Aktivieren Sie ip_forwarding:
[user @ local ~] $ grep ip_forward /etc/sysctl.conf net.ipv4.ip_forward = 1 [user @ local ~] $ sudo service network restart Neustart des Netzwerks (über systemctl): [OK]
Richten Sie die Paketerfassung auf einem lokalen Computer mit tcpdump ein:
[user @ local ~] $ sudo tcpdump -nn -vv 'port not 22' -i any tcpdump: Abhören eines beliebigen LINUX_SLL vom Link-Typ (Linux gekocht) mit einer Größe von 65535 Byte
Versuchen Sie, vom Remote-Server aus eine Verbindung zu Google herzustellen.
[user @ remote ~] $ openssl s_client -connect google.com:443 Socket: Keine Route zum Host connect: errno = 113
Sobald der Befehl openssl 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, options [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, options [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, options [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, options [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, options [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, options [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, options [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], Länge 0
^ C.
13 Pakete erfasst
13 vom Filter empfangene Pakete
0 Pakete vom Kernel verworfen
Die mit tcpdump erfassten Pakete deuten darauf hin, dass versucht wird, die Verbindung herzustellen (Synchronisierungspakete werden gesendet), aber nichts empfangen wird. Es gibt auch 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 hindeutet.
Irgendwelche Vorschläge, wie Sie dieses Problem umgehen können? Gibt es iptable Regeln, die hinzugefügt werden müssen? Probleme mit der Firewall (Firewall-d?).
Hinweis Nr. 1
Ausgabe von 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 # Erstellt von iptables-save v1.4.21 am Sat Apr 15 01:40:57 2017 * nat : PREROUTING ACCEPT [35: 8926] : INPUT ACCEPT [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 -A OUTPUT -j OUTPUT_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 MASKERADE -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 VERPFLICHTEN # Abgeschlossen am Sat Apr 15 01:40:57 2017 # Erstellt von iptables-save v1.4.21 am Sat Apr 15 01:40:57 2017 *Mangel : PREROUTING ACCEPT [169: 18687] : INPUT ACCEPT [144: 11583] : FORWARD ACCEPT [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 -A 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 VERPFLICHTEN # Abgeschlossen am Sat Apr 15 01:40:57 2017 # Erstellt von iptables-save v1.4.21 am Sat Apr 15 01:40:57 2017 *Sicherheit : INPUT ACCEPT [2197: 163931] : FORWARD ACCEPT [0: 0] : OUTPUT ACCEPT [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 OUTPUT -j OUTPUT_direct VERPFLICHTEN # Abgeschlossen am Sat Apr 15 01:40:57 2017 # Erstellt von iptables-save v1.4.21 am Sat Apr 15 01:40:57 2017 *roh : PREROUTING ACCEPT [2362: 184437] : OUTPUT ACCEPT [1229: 185742] : OUTPUT_direct - [0: 0] : PREROUTING_direct - [0: 0] -A PREROUTING -j PREROUTING_direct -A OUTPUT -j OUTPUT_direct VERPFLICHTEN # Abgeschlossen am Sat Apr 15 01:40:57 2017 # Erstellt von iptables-save v1.4.21 am Sat Apr 15 01:40:57 2017 *Filter : INPUT ACCEPT [0: 0] : FORWARD ACCEPT [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 RELATED, ESTABLISHED -j ACCEPT -A EINGANG -i lo -j AKZEPTIEREN -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-with icmp-host-verboten -A FORWARD -m conntrack --ctstate RELATED, ESTABLISHED -j ACCEPT -A FORWARD -i lo -j AKZEPTIEREN -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-verboten -A 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 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 ACCEPT -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT VERPFLICHTEN # Abgeschlossen am Sat Apr 15 01:40:57 2017
Hinweis 2:
Ich habe einen Apache-Webserver auf einem separaten Host eingerichtet, auf den nur der lokale Server Zugriff hat. Ich habe tcpdump auf einem Webserver ausgeführt, der Port 80 überwacht. Wenn ich ausgeführt
telnet webserver 80werde, erhalte ich die folgenden Pakete. Dies ist das erwartete Verhalten, da die TCP-Verbindung hergestellt wurde (S, S-Ack, Ack).
[user @ webserver ~] $ sudo tcpdump -nn -vv 'Port nicht 22 und 80' -i eth0
tcpdump: Abhören von eth0, Verbindungstyp EN10MB (Ethernet), Erfassungsgröße 65535 Byte
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, options [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, options [mss 1460, sackOK, TS val 37704524 ecr 3047398, nop , Skala 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, options [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 verhindert, dass die Pakete an den Webserver gesendet werden - möglicherweise eine Fehlkonfiguration oder eine Firewall.
[user @ local ~] $ sudo tcpdump -nn -vv 'Port nicht 22 und 80' -i any
tcpdump: Abhören eines beliebigen LINUX_SLL vom Link-Typ (Linux gekocht) mit einer Größe von 65535 Byte
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, options [mss 1460, sackOK, TS val 4780524 ecr 0, nop, wscale 7], Länge 0
WICHTIG: Die Pakete werden nicht über eth0 geleitet, 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:
[user @ local ~] $ sudo tcpdump -nn -vv 'Port nicht 22 und 80' -i tun0
tcpdump: Abhören von tun0, RAW vom Verbindungstyp (Raw IP), Erfassungsgröße 65535 Byte
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, options [mss 1460, sackOK, TS val 5021684 ecr 0, nop, wscale 7], Länge 0
Hinweis 3:
Ich habe die Firewall auf dem lokalen Computer deaktiviert und Synchronisierungspakete wurden vom Webserver empfangen.
[user @ local ~] $ sudo systemctl stop firewalld
[user @ webserver ~] $ sudo tcpdump -nn -vv 'Port nicht 22 und 80' -i eth0
tcpdump: Abhören von eth0, Verbindungstyp EN10MB (Ethernet), Erfassungsgröße 65535 Byte
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, options [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, options [mss 1460, sackOK, TS val 41771503 ecr 7123514, nop , Skala 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, options [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, options [mss 1460, sackOK, TS val 41772506 ecr 7124517, nop , Skala 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 eindeutig aktualisiert werden, damit sie mit der IP-Adresse des lokalen Servers übereinstimmt, bevor das Paket an den Webserver gesendet wird. Wie von @xin vorgeschlagen, muss NAT auf dem lokalen Server eingerichtet werden.
Hinweis 4:
Sobald ich versuche, eine Verbindung zum Webserver herzustellen, kann ich sehen, dass die Anzahl der pkts für Regel 9 um 1 steigt (siehe unten).
[user @ local ~] $ sudo iptables -nvL - Zeilennummern .......... Chain FORWARD (Richtlinie AKZEPTIERT 0 Pakete, 0 Bytes) Anzahl pkts Bytes Ziel prot opt in out Quellziel 1 0 0 ACCEPT all - * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED, ESTABLISHED 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 all - * * 0.0.0.0/0 0.0.0.0/0 5 1 60 FORWARD_IN_ZONES all - * * 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 all - * * 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 Alle ablehnen - * * 0.0.0.0/0 0.0.0.0/0 ablehnen-mit icmp-host-verboten .......... [user @ local ~] $ sudo iptables -D FORWARD 9
Sobald Regel 9 aus der FORWARD-Kette gelöscht ist (von oben, wie von @xin vorgeschlagen), kann ich eine Verbindung zum Webserver herstellen.
[user @ local ~] $ sudo iptables -nvL - Zeilennummern .......... Chain FORWARD (Richtlinie 1 Pakete akzeptieren, 60 Bytes) Anzahl pkts Bytes Ziel prot opt in out Quellziel 1 12 5857 ACCEPT all - * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED, ESTABLISHED 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 all - * * 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 all - * * 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 ..........