Oto problem, który próbuję rozwiązać. Istnieje serwer („system zdalny”), do którego mogę ssh z mojego komputera lokalnego, ale ten zdalny system nie ma połączenia z Internetem. Chcę zapewnić zdalnemu systemowi dostęp do Internetu za pośrednictwem lokalnego komputera za pomocą sieci VPN opartej na ssh. Jak to osiągnąć? Próbowałem następujących, które wydają się częściowo działać. Rozumiem przez „częściową pracę”, że pakiety połączenia (pakiety synchronizacji) są wysyłane na mój komputer lokalny, ale nie nawiązują połączenia z Internetem. Używam tcpdump do przechwytywania pakietów na komputerze lokalnym. Komputer lokalny i system zdalny działają w systemie centos 7.
Konfiguracja - Uwaga: poniższe polecenia są uruchamiane w kolejności. Polecenia użytkownika @ zdalne są uruchamiane na serwerze zdalnym, a polecenia użytkownika @ lokalne są uruchamiane na komputerze lokalnym.
[user @ remote ~] $ ip addr show
1: lo: mtu 65536 qdisc stan noqueue NIEZNANY
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 zakres host lo
valid_lft na zawsze preferowany_lft na zawsze
Host inet6 :: 1/128
valid_lft na zawsze preferowany_lft na zawsze
2: eth0: mtu 1500 qdisc pfifo_fast stan UP qlen 1000
link / ether AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 zakres globalny dynamiczny eth0
valid_lft 1785sec preferowany_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: zakres LLLL / 64 globalny noprefixroute dynamic
valid_lft 2591987sec prefer_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 link do zakresu
valid_lft na zawsze preferowany_lft na zawsze
[użytkownik @ lokalny ~] $ ip addr show
1: lo: mtu 65536 qdisc stan noqueue NIEZNANY
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 zakres host lo
valid_lft na zawsze preferowany_lft na zawsze
Host inet6 :: 1/128
valid_lft na zawsze preferowany_lft na zawsze
2: eth0: mtu 1500 qdisc pfifo_fast stan UP qlen 1000
link / ether AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 zakres globalny dynamiczny eth0
valid_lft 1785sec preferowany_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: zakres LLLL / 64 globalny noprefixroute dynamic
valid_lft 2591987sec prefer_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 link do zakresu
valid_lft na zawsze preferowany_lft na zawsze
Utwórz interfejs tun0 na zdalnym systemie.
[user @ remote ~] $ sudo ip tuntap dodaj tryb tun0 tun
[user @ remote ~] $ ip addr show
1: lo: mtu 65536 qdisc stan noqueue NIEZNANY
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 zakres host lo
valid_lft na zawsze preferowany_lft na zawsze
Host inet6 :: 1/128
valid_lft na zawsze preferowany_lft na zawsze
2: eth0: mtu 1500 qdisc pfifo_fast stan UP qlen 1000
link / ether AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 zakres globalny dynamiczny eth0
valid_lft 1785sec preferowany_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: zakres LLLL / 64 globalny noprefixroute dynamic
valid_lft 2591987sec prefer_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 link do zakresu
valid_lft na zawsze preferowany_lft na zawsze
3: tun0: mtu 1500 qdisc stan noop W DÓŁ qlen 500
link / none
Utwórz interfejs tun0 w systemie lokalnym .
[użytkownik @ lokalny ~] $ sudo ip tuntap dodaj tryb tun0 tun
[użytkownik @ lokalny ~] $ ip addr show
1: lo: mtu 65536 qdisc stan noqueue NIEZNANY
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 zakres host lo
valid_lft na zawsze preferowany_lft na zawsze
Host inet6 :: 1/128
valid_lft na zawsze preferowany_lft na zawsze
2: eth0: mtu 1500 qdisc pfifo_fast stan UP qlen 1000
link / ether AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 zakres globalny dynamiczny eth0
valid_lft 1785sec preferowany_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: zakres LLLL / 64 globalny noprefixroute dynamic
valid_lft 2591987sec prefer_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 link do zakresu
valid_lft na zawsze preferowany_lft na zawsze
3: tun0: mtu 1500 qdisc stan noop W DÓŁ qlen 500
link / none
Przypisz adres IP tun0 i wyświetl go:
[użytkownik @ lokalny ~] $ sudo ip addr add 10.0.2.1/30 dev tun0
[użytkownik @ lokalny ~] $ sudo ip link set dev tun0 up
[użytkownik @ lokalny ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast stan W DÓŁ qlen 500
link / none
inet 10.0.2.1/30 zakres globalny tun0
valid_lft na zawsze preferowany_lft na zawsze
[user @ remote ~] $ sudo ip addr add 10.0.2.2/30 dev tun0
[user @ remote ~] $ sudo ip link set dev tun0 up
[użytkownik @ zdalny ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast stan W DÓŁ qlen 500
link / none
inet 10.0.2.2/30 zakres globalny tun0
valid_lft na zawsze preferowany_lft na zawsze
Zmodyfikuj sshd_config zarówno w systemie zdalnym, jak i lokalnym, aby włączyć tunelowanie:
[użytkownik @ zdalny ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config PermitTunnel punkt-punkt
[użytkownik @ lokalny ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config PermitTunnel punkt-punkt
Utwórz tunel ssh:
[użytkownik @ lokalny ~] $ sudo ssh -f -w0: 0 root @ remote true root @ hasło zdalnego: [użytkownik @ lokalny ~] $ ps aux | grep root @ remote korzeń 1851 0,0 0,0 76112 1348? Ss 23:12 0:00 ssh -f -w0: 0 root @ remote true
Przetestuj ping na obu serwerach, używając nowych adresów IP:
[użytkownik @ lokalny ~] $ ping 10.0.2.2 -c 2 PING 10.0.2.2 (10.0.2.2) 56 (84) bajtów danych. 64 bajty od 10.0.2.2: icmp_seq = 1 ttl = 64 czas = 1,68 ms 64 bajty od 10.0.2.2: icmp_seq = 2 ttl = 64 czas = 0,861 ms --- 10.0.2.2 statystyki ping --- 2 pakiety przesłane, 2 odebrane, 0% utraty pakietu, czas 1002 ms rtt min / avg / max / mdev = 0,861 / 1,274 / 1,688 / 0,415 ms
[użytkownik @ zdalny ~] $ ping 10.0.2.1 -c 2 PING 10.0.2.1 (10.0.2.1) 56 (84) bajtów danych. 64 bajty od 10.0.2.1: icmp_seq = 1 ttl = 64 czas = 0,589 ms 64 bajty od 10.0.2.1: icmp_seq = 2 ttl = 64 czas = 0,889 ms --- 10.0.2.1 statystyki ping --- 2 pakiety przesłane, 2 odebrane, 0% utraty pakietu, czas 1000ms rtt min / avg / max / mdev = 0,589 / 0,739 / 0,889 / 0,150 ms
[użytkownik @ zdalny ~] $ route Tabela routingu IP jądra Brama docelowa Genmask Flagi Metryka Ref Użyj Iface brama domyślna 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 show route domyślnie przez AAA.BBB.CCC.1 dev eth0 proto static metric 100 10.0.2.0/30 dev tun0 proto link do zakresu jądra src 10.0.2.2 AAA.BBB.CCC.0 / 24 dev eth0 proto link zakresu jądra src AAA.BBB.CCC.31 metryczny 100
Uzyskaj adresy IP Google:
[użytkownik @ lokalny ~] $ nslookup google.com Serwer: serwer Adres: serwer nr 53 Odpowiedź nieautorytatywna: Nazwa: google.com Adres: 173.194.219.101 Nazwa: google.com Adres: 173.194.219.100 Nazwa: google.com Adres: 173.194.219.113 Nazwa: google.com Adres: 173.194.219.102 Nazwa: google.com Adres: 173.194.219.139 Nazwa: google.com Adres: 173.194.219.138
WAŻNE: Uruchomiłem powyższe polecenie w innym czasie i uzyskałem inny wynik. Nie zakładaj, że twoja odpowiedź będzie taka sama jak moja dla nslookup powyżej.
Ponieważ wszystkie adresy IP Google zaczynają się od 173.194.219, pozwól nam przekierować wszystkie te adresy IP przez komputer lokalny.
[użytkownik @ zdalny ~] $ sudo ip route add 173.194.219.0/24 dev tun0 [użytkownik @ zdalny ~] $ route Tabela routingu IP jądra Brama docelowa Genmask Flagi Metryka Ref Użyj Iface brama domyślna 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 show route domyślnie przez AAA.BBB.CCC.1 dev eth0 proto static metric 100 10.0.2.0/30 dev tun0 proto link do zakresu jądra src 10.0.2.2 AAA.BBB.CCC.0 / 24 dev eth0 proto link zakresu jądra src AAA.BBB.CCC.31 metryczny 100 173.194.219.0/24 dev tun0 link do zakresu
Włącz ip_forwarding:
[użytkownik @ lokalny ~] $ grep ip_forward /etc/sysctl.conf net.ipv4.ip_forward = 1 [użytkownik @ lokalny ~] $ sudo restart sieci Ponowne uruchamianie sieci (przez systemctl): [OK]
Skonfiguruj przechwytywanie pakietów na komputerze lokalnym za pomocą tcpdump:
[użytkownik @ lokalny ~] $ sudo tcpdump -nn -vv 'port nie 22' -i dowolny tcpdump: nasłuchuje na dowolnym LINUX_SLL typu linuksowego (Linux gotowy), przechwytuje rozmiar 65535 bajtów
Spróbuj połączyć się z Google ze zdalnego serwera.
[użytkownik @ zdalny ~] $ openssl s_client -connect google.com:443 gniazdo: Brak trasy do hosta połącz: errno = 113
Gdy tylko komenda openssl zostanie uruchomiona na zdalnym serwerze, tcpdump przechwytuje niektóre pakiety:
10.0.2.2.52768> 173.194.219.102.443: Flagi [S], cksum 0x8702 (poprawnie), seq 994650730, win 29200, opcje [mss 1460, sackOK, TS val 7701438 ecr 0, nop, wscale 7], długość 0
00: 49: 33.247753 IP (tos 0x0, tl 64, id 46037, przesunięcie 0, flagi [DF], proto TCP (6), długość 60)
10.0.2.2.48774> 173.194.219.100.443: Flagi [S], cksum 0x47a7 (poprawnie), seq 2218733674, win 29200, opcje [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], długość 0
00: 49: 33.247883 IP (tos 0xc0, tl 64, id 9538, przesunięcie 0, flagi [brak], proto ICMP (1), długość 88)
10.0.2.1> 10.0.2.2: Host ICMP 173.194.219.100 nieosiągalny - administrator zabroniony, długość 68
IP (tos 0x0, tl 63, id 46037, offset 0, flagi [DF], proto TCP (6), długość 60)
10.0.2.2.48774> 173.194.219.100.443: Flagi [S], cksum 0x47a7 (poprawnie), seq 2218733674, win 29200, opcje [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], długość 0
00: 49: 33.253068 IP (tos 0x0, tl 64, id 26282, przesunięcie 0, flagi [DF], proto TCP (6), długość 60)
10.0.2.2.51312> 173.194.219.101.443: Flagi [S], cksum 0x6ff8 (poprawnie), seq 2634016105, win 29200, opcje [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], długość 0
00: 49: 33.254771 IP (tos 0xc0, ttl 64, id 9539, offset 0, flagi [brak], proto ICMP (1), długość 88)
10.0.2.1> 10.0.2.2: Host ICMP 173.194.219.101 nieosiągalny - administrator zabroniony, długość 68
IP (tos 0x0, tl 63, id 26282, offset 0, flagi [DF], proto TCP (6), długość 60)
10.0.2.2.51312> 173.194.219.101.443: Flagi [S], cksum 0x6ff8 (poprawnie), seq 2634016105, win 29200, opcje [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], długość 0
00: 49: 33.258805 IP (tos 0x0, tl 64, id 9293, przesunięcie 0, flagi [DF], proto TCP (6), długość 60)
10.0.2.2.33686> 173.194.219.139.443: Flagi [S], cksum 0x542b (poprawnie), seq 995927943, win 29200, opcje [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], długość 0
00: 49: 33.258845 IP (tos 0xc0, tl 64, id 9540, przesunięcie 0, flagi [brak], proto ICMP (1), długość 88)
10.0.2.1> 10.0.2.2: Host ICMP 173.194.219.139 nieosiągalny - administrator zabroniony, długość 68
IP (tos 0x0, tl 63, id 9293, offset 0, flagi [DF], proto TCP (6), długość 60)
10.0.2.2.33686> 173.194.219.139.443: Flagi [S], cksum 0x542b (poprawnie), seq 995927943, win 29200, opcje [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], długość 0
^ C
Przechwycono 13 pakietów
13 pakietów odebranych przez filtr
0 pakietów upuszczonych przez jądro
Pakiety przechwycone przy użyciu tcpdump sugerują, że podjęto próbę nawiązania połączenia (pakiety synchronizacji są wysyłane), ale nic nie jest odbierane. Jest też komunikat, 10.0.2.1 > 10.0.2.2: ICMP host 173.194.219.139 unreachable - admin prohibited, length 68który wydaje się sugerować problem.
Wszelkie sugestie dotyczące obejścia tego problemu? Czy istnieją iptable reguły, które należy dodać? Wszelkie problemy z zaporą ogniową (firewall-d?).
Uwaga nr 1 Dane
wyjściowe z iptables-save:
[użytkownik @ lokalny ~] $ sudo iptables -t nat -A POSTROUTING -s 10.0.2.2/32! -d 10.0.2.1/30 -j MASQUERADE -o eth0 [użytkownik @ lokalny ~] $ sudo iptables-save # Wygenerowane przez iptables-save v1.4.21 w sob. 15 kwietnia 01:40:57 2017 * nat : AKCEPTACJA WSTĘPNA [35: 8926] : AKCEPTACJA WEJŚCIA [1:84] : AKCEPTACJA WYJŚCIA [6: 439] : AKCEPTACJA POSTROUTINGU [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 WYJŚCIE -j OUTPUT_direct -A POSTROUTING -j POSTROUTING_direct -A POSTROUTING -j POSTROUTING_ZONES_SOURCE -A POSTROUTING -j POSTROUTING_ZONES -A POSTROUTOWANIE -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_publiczna -j PRE_publiczna_deny -A PRE_publiczny -j PRE_publiczny_allow POPEŁNIĆ # Ukończone sob 15 kwietnia 01:40:57 2017 # Wygenerowane przez iptables-save v1.4.21 w sob. 15 kwietnia 01:40:57 2017 *magiel : AKCEPTACJA WSTĘPNA [169: 18687] : AKCEPTACJA WEJŚCIA [144: 11583] : AKCEPTACJA DO PRZODU [0: 0] : AKCEPTACJA WYJŚCIA [80: 8149] : AKCEPTACJA POSTROUTINGU [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 WEJŚCIE -j WEJŚCIE_dysk -A DO PRZODU -j DO PRZODU_direct -A WYJŚCIE -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_publiczna -j PRE_publiczna_deny -A PRE_publiczny -j PRE_publiczny_allow POPEŁNIĆ # Ukończone sob 15 kwietnia 01:40:57 2017 # Wygenerowane przez iptables-save v1.4.21 w sob. 15 kwietnia 01:40:57 2017 *bezpieczeństwo : AKCEPTACJA WEJŚCIA [2197: 163931] : AKCEPTACJA DO PRZODU [0: 0] : AKCEPTACJA WYJŚCIA [1229: 185742] : FORWARD_direct - [0: 0] : INPUT_direct - [0: 0] : OUTPUT_direct - [0: 0] -A WEJŚCIE -j WEJŚCIE_dysk -A DO PRZODU -j DO PRZODU_direct -A WYJŚCIE -j OUTPUT_direct POPEŁNIĆ # Ukończone sob 15 kwietnia 01:40:57 2017 # Wygenerowane przez iptables-save v1.4.21 w sob. 15 kwietnia 01:40:57 2017 *surowy : AKCEPTACJA WSTĘPNA [2362: 184437] : AKCEPTACJA WYJŚCIA [1229: 185742] : OUTPUT_direct - [0: 0] : PREROUTING_direct - [0: 0] -A PREROUTING -j PREROUTING_direct -A WYJŚCIE -j OUTPUT_direct POPEŁNIĆ # Ukończone sob 15 kwietnia 01:40:57 2017 # Wygenerowane przez iptables-save v1.4.21 w sob. 15 kwietnia 01:40:57 2017 *filtr : AKCEPTACJA WEJŚCIA [0: 0] : AKCEPTACJA DO PRZODU [0: 0] : AKCEPTACJA WYJŚCIA [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 WEJŚCIE -m conntrack --ctstate POWIĄZANE, USTALONE -j AKCEPTUJ -A WEJŚCIE -i lo -j AKCEPTUJĘ -A WEJŚCIE -j WEJŚCIE_dysk -A WEJŚCIE -j INPUT_ZONES_SOURCE -A WEJŚCIE -j WEJŚCIE_ZONES -A WEJŚCIE -m conntrack --ctstate NIEPRAWIDŁOWY -j DROP -A WEJŚCIE -j ODRZUĆ --reject-with icmp-host-zabronione -A DO PRZODU -m conntrack -ctstate POWIĄZANE, USTALONE -j AKCEPTUJĘ -A DO PRZODU -i lo -j AKCEPTUJĘ -A DO PRZODU -j DO PRZODU_direct -A DO PRZODU -j FORWARD_IN_ZONES_SOURCE -A DO PRZODU -j FORWARD_IN_ZONES -A DO PRZODU -j FORWARD_OUT_ZONES_SOURCE -A DO PRZODU -j FORWARD_OUT_ZONES -A DO PRZODU -m conntrack --ctstate INVALID -j DROP -A DO PRZODU -j ODRZUĆ -reject-with icmp-host-zabronione -A WYJŚCIE -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 AKCEPTUJ -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_publiczna -A INPUT_ZONES -g IN_publiczne -A IN_publiczny -j IN_publiczny_log -A IN_publiczne -j IN_publiczne_deny -A IN_publiczny -j IN_publiczny_allow -A IN_publiczna -p icmp -j AKCEPTUJ -A IN_publiczny_allow -p tcp -m tcp --port 22 -m conntrack --ctstate NOWOŚĆ -j AKCEPTUJ POPEŁNIĆ # Ukończone sob 15 kwietnia 01:40:57 2017
Uwaga 2:
Instaluję serwer Apache na oddzielnym hoście, do którego ma dostęp tylko serwer lokalny. Uruchomiłem tcpdump na serwerze sieciowym nasłuchującym na porcie 80. Po uruchomieniu
telnet webserver 80przechwytuję następujące pakiety. Jest to oczekiwane zachowanie od momentu ustanowienia połączenia TCP (S, S-Ack, Ack).
[user @ webserver ~] $ sudo tcpdump -nn -vv 'port nie 22 i 80' -i eth0
tcpdump: nasłuch na eth0, typ łącza EN10MB (Ethernet), przechwytywanie rozmiaru 65535 bajtów
07: 17: 30.411474 IP (tos 0x10, tl 64, id 34376, przesunięcie 0, flagi [DF], proto TCP (6), długość 60)
local.server.46710> web.server.80: Flagi [S], cksum 0x8412 (niepoprawne -> 0x6d96), seq 3018586542, win 29200, opcje [mss 1460, sackOK, TS val 3047398 ecr 0, nop, wscale 7] , długość 0
07: 17: 30.411557 IP (tos 0x0, tl 64, id 0, offset 0, flagi [DF], proto TCP (6), długość 60)
web.server.80> local.server.46710: Flagi [S.], cksum 0x8412 (niepoprawne -> 0x9114), seq 2651711943, ack 3018586543, win 28960, opcje [mss 1460, sackOK, TS val 37704524 ecr 3047398, nop , wscale 7], długość 0
07: 17: 30.411725 IP (tos 0x10, tl 64, id 34377, przesunięcie 0, flagi [DF], proto TCP (6), długość 52)
local.server.46710> web.server.80: Flags [.], cksum 0x840a (niepoprawny -> 0x301c), seq 1, ack 1, win 229, opcje [nop, nop, TS val 3047398 ecr 37704524], długość 0
Kiedy próbuję połączyć się z serwerem zdalnym z serwera zdalnego przez serwer lokalny, tcpdump na serwerze nie przechwytuje żadnych pakietów (nawet początkowej synchronizacji), ale serwer lokalny przechwytuje pakiet synchronizacji wysyłany do serwera (patrz poniżej). To sprawia, że wierzę, że coś uniemożliwia wysyłanie pakietów do serwera WWW - być może błędna konfiguracja lub zapora ogniowa.
[użytkownik @ lokalny ~] $ sudo tcpdump -nn -vv 'port nie 22 i 80' -i dowolny
tcpdump: nasłuchuje na dowolnym LINUX_SLL typu linuksowego (Linux gotowy), przechwytuje rozmiar 65535 bajtów
02: 24: 09.135842 IP (tos 0x10, tl 64, id 38062, offset 0, flagi [DF], proto TCP (6), długość 60)
10.0.2.2.50558> web.server.80: Flagi [S], cksum 0x668d (poprawnie), seq 69756226, win 29200, opcje [mss 1460, sackOK, TS val 4780524 ecr 0, nop, wscale 7], długość 0
WAŻNE: pakiety nie są kierowane przez eth0, ale zamiast tego podejmowana jest próba wysłania pakietów do serwera przez tun0 (co się nie powiedzie). Mogę to potwierdzić, uruchamiając tcpdump na interfejsie tun0:
[użytkownik @ lokalny ~] $ sudo tcpdump -nn -vv 'port nie 22 i 80' -i tun0
tcpdump: nasłuchuje na tun0, RAW typu link (Raw IP), przechwytuje rozmiar 65535 bajtów
02: 28: 10.295972 IP (tos 0x10, tl 64, id 46976, offset 0, flagi [DF], proto TCP (6), długość 60)
10.0.2.2.50560> webserver.80: Flagi [S], cksum 0xd560 (poprawnie), seq 605366388, win 29200, opcje [mss 1460, sackOK, TS val 5021684 ecr 0, nop, wscale 7], długość 0
Uwaga 3:
Wyłączyłem firewalld na komputerze lokalnym i pakiety synchronizacji zostały odebrane przez serwer WWW.
[użytkownik @ lokalny ~] $ sudo systemctl stop firewalld
[user@webserver ~]$ sudo tcpdump -nn -vv 'port not 22 and 80' -i eth0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:25:17.390912 IP (tos 0x10, ttl 63, id 61767, offset 0, flags [DF], proto TCP (6), length 60)
10.0.2.2.50580 > web.server.80: Flags [S], cksum 0x30dc (correct), seq 2601927549, win 29200, options [mss 1460,sackOK,TS val 7123514 ecr 0,nop,wscale 7], length 0
08:25:17.391003 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
web.server.80 > 10.0.2.2.50580: Flags [S.], cksum 0x4e23 (incorrect -> 0xa316), seq 959115533, ack 2601927550, win 28960, options [mss 1460,sackOK,TS val 41771503 ecr 7123514,nop,wscale 7], length 0
08:25:17.391192 IP (tos 0x0, ttl 128, id 60032, offset 0, flags [none], proto TCP (6), length 40)
10.0.2.2.50580 > web.server.80: Flags [R], cksum 0x7339 (correct), seq 2601927550, win 8192, length 0
08:25:18.393794 IP (tos 0x10, ttl 63, id 61768, offset 0, flags [DF], proto TCP (6), length 60)
10.0.2.2.50580 > web.server.80: Flags [S], cksum 0x2cf1 (correct), seq 2601927549, win 29200, options [mss 1460,sackOK,TS val 7124517 ecr 0,nop,wscale 7], length 0
08:25:18.393898 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
web.server.80 > 10.0.2.2.50580: Flags [S.], cksum 0x4e23 (incorrect -> 0x7e71), seq 974785773, ack 2601927550, win 28960, options [mss 1460,sackOK,TS val 41772506 ecr 7124517,nop,wscale 7], length 0
08:25:18.394003 IP (tos 0x0, ttl 128, id 60033, offset 0, flags [none], proto TCP (6), length 40)
10.0.2.2.50580> web.server.80: Flagi [R], cksum 0x566a (poprawnie), sekw. 2601927550, wygrana 8192, długość 0
Oczywiście, źródłowy adres IP musi zostać zaktualizowany, aby pasował do adresu IP lokalnego serwera, zanim pakiet zostanie wysłany do serwera WWW. Jak sugerował @xin, NAT musi zostać skonfigurowany na serwerze lokalnym.
Uwaga # 4:
Kiedy próbuję połączyć się z serwerem internetowym, widzę, że liczba punktów dla reguły 9 wzrasta o 1 (jak pokazano poniżej).
[użytkownik @ lokalny ~] $ sudo iptables -nvL --line-numbers .......... Chain FORWARD (polityka AKCEPTUJE 0 pakietów, 0 bajtów) num pkts bajty target prot opt w źródłowym źródle docelowym 1 0 0 AKCEPTUJ wszystko - * * 0,0,0,0/0 0,0,0,0/0 ctstate POWIĄZANE, USTANOWIONE 2 0 0 AKCEPTUJ wszystko - 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 wszystkie - * * 0.0.0.0/0 0.0.0.0/0 5 1 60 FORWARD_IN_ZONES wszystkie - * * 0,0,0,0/0 0,0,0,0/0 6 1 60 FORWARD_OUT_ZONES_SOURCE wszystkie - * * 0.0.0.0/0 0.0.0.0/0 7 1 60 FORWARD_OUT_ZONES wszystkie - * * 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 ODRZUĆ wszystko - * * 0.0.0.0/0 0.0.0.0/0 odrzucenie z icmp-host-zabronione .......... [użytkownik @ lokalny ~] $ sudo iptables -D DO PRZODU 9
Po usunięciu reguły 9 z łańcucha FORWARD (z góry, jak sugerował @xin), mogę połączyć się z serwerem internetowym.
[użytkownik @ lokalny ~] $ sudo iptables -nvL --line-numbers .......... Chain FORWARD (polityka AKCEPTUJE 1 pakiety, 60 bajtów) num pkts bajty target prot opt w źródłowym źródle docelowym 1 12 5857 AKCEPTUJ wszystko - * * 0,0,0,0/0 0,0,0,0/0 ctstate POWIĄZANE, USTANOWIONE 2 0 0 AKCEPTUJ wszystko - 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 wszystkie - * * 0.0.0.0/0 0.0.0.0/0 5 2 120 FORWARD_IN_ZONES wszystkie - * * 0,0,0,0/0 0,0,0,0/0 6 2 120 FORWARD_OUT_ZONES_SOURCE wszystkie - * * 0.0.0.0/0 0.0.0.0/0 7 2 120 FORWARD_OUT_ZONES wszystkie - * * 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 ..........