Wie erstelle / richte ich VPN mit nur SSH ein?

9

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
..........
Ali
quelle

Antworten:

4

Die Quelladresse von Paketen sollte durch eine der Adressen des lokalen Computers ersetzt werden, damit Antworten vom lokalen Computer empfangen werden können. Andernfalls gibt es keinen (guten) Grund, diese Pakete an die nächsten Router zu senden. Die Antwort konnte ohnehin nicht abgefangen werden. 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
xin
quelle
Danke für die Antwort @xin. Ich habe den von Ihnen angegebenen Befehl ausgeführt, aber immer noch die gleiche Antwort erhalten. Ich habe tcpdump auf eth0 und tun0 ausgeführt. Pakete werden nicht an eth0 weitergeleitet. tun0 versucht immer noch, Google zu erreichen. Muss ich Pakete irgendwie von tun0 nach eth0 weiterleiten?
Ali
1
Wenn der lokale Computer die Schnittstelle eth0 verwendet, um eine Verbindung zum Internet herzustellen, sollten Pakete auch ohne diesen Befehl an eth0 gesendet werden. Vielleicht ist also eine Firewall-Einstellung beteiligt. Können Sie die iptables-saveAusgabe der lokalen Maschine setzen?
Xin
Ich habe die Ausgabe von iptables-save zum ursprünglichen Beitrag hinzugefügt.
Ali
Die Firewall musste ausgeschaltet werden. Ich habe Ihren Befehl ausgeführt, nachdem ich firewalld ausgeschaltet hatte, und die Verbindung begann zu funktionieren! Schätze deine Hilfe! Checkout-Hinweise im Originalbeitrag, um den Fortschritt zu sehen.
Ali
1
Gut gemacht. Es sieht so aus, als ob das Problem eine Iptable-Regel ist -A FORWARD -j REJECT --reject-with icmp-host-prohibited. Pakete, die auf Ihrem Computer eingehen und deren Zieladresse nicht auf Ihrem Computer vorhanden ist, werden an die FORWARD-Kette gesendet. Löschen Sie diese Regel.
Xin