AWS VPC + IPtables + NAT: Przekazywanie portów nie działa

Wczoraj zadałem tutaj pytanie , ale myślę, że moje słowa nie były wystarczająco jasne. BTW, to pytanie nie jest duplikatem.

Mam konfigurację AWS VPC, jak poniżej.

CEL / PROBLEM : SSH do serwera A z Internetu. I to nie działa.

Serwer A znajduje się w prywatnej podsieci, dlatego chcę włączyć NAT iptables w mojej instancji NAT, aby móc ssh do SErver A bezpośrednio z Internetu

Śledzę to i to

Uruchomiłem poniżej polecenia dla instancji NAT:

NAT# iptables -t nat -A PREROUTING  -p tcp --dport 2222 -j DNAT --to-destination 10.0.1.243:22

Przekazywanie IP jest włączone w instancji NAT:

NAT# sysctl  -p
net.ipv4.ip_forward = 1

MASQUERADE działa na instancji NAT:

NAT# iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 6 packets, 312 bytes)
 pkts bytes target     prot opt in     out     source               destination
  199 16466 MASQUERADE  all  --  *      eth0    10.0.0.0/16          0.0.0.0/0

Grupy zabezpieczeń AWS są odpowiednio skonfigurowane, aby umożliwić różny dostęp wymagany dla tego przypadku testowego.

Rozwiązywanie problemów:

Mogę telnet z NAT na serwer A na porcie 22. Tak więc Access jest dobry.

Kiedy uruchamiam telnet 54.213.116.251 2222na swoim laptopie, widzę poniżej wpis w tcpdump na NAT:

NAT# tcpdump -n -i eth0 dst 10.0.1.243 and port 22
09:59:13.738316 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
09:59:16.737009 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
09:59:22.775567 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,nop,sackOK], length 0

Oznacza to, że iptables kieruje pakiety do 10.0.1.243. (BTW, xxx.xxx.xxx.xxxto publiczny adres IP mojego laptopa)

Ale kiedy uruchamiam tcpdump na serwerze A, nie widzę niczego, z 10.0.0.54czego pochodzi wewnętrzny / prywatny adres NAT NAT ( i myślę, że to jest problem ):

Server A# tcpdump  -n src 10.0.0.54
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 

Ale jeśli telnet z instancji NAT na serwer A, widzę dobre rzeczy w tcpdump na serwerze A ( oznacza to, że moja ogólna PREROUTINGreguła nie działa zgodnie z oczekiwaniami ):

Server A# tcpdump  -n src 10.0.0.54
05:01:47.500080 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [S], seq 2862522431, win 14600, options [mss 1460,sackOK,TS val 3013083 ecr 0,nop,wscale 7], length 0
05:01:47.501601 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [.], ack 760676524, win 115, options [nop,nop,TS val 3013083 ecr 12074896], length 0
05:01:47.535720 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [.], ack 22, win 115, options [nop,nop,TS val 3013092 ecr 12074928], length 0

Wniosek:

Z danych wyjściowych tcpdump na NAT, wygląda na to, że Iptables dobrze przekazuje moje pakiety.

ze zrzutu TCP na serwerze A, mam dobrą łączność z NAT do serwera A.

Ale w systemie End-to-End nie mogę połączyć się z serwerem A z mojego laptopa.

( BTW, znam tunel SSH i inne dobre rzeczy. Ale chcę tylko Iptables, aby mi w tym pomóc. )

Wreszcie go złamałem !!!!

W instancji NAT musiałem zmienić poniższe polecenie:

Od:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/16 -j MASQUERADE

Do:

iptables -t nat -A POSTROUTING -j MASQUERADE

I zadziałało !!!!

Tak więc wkrótce utworzę nowe pytanie na ServerFault, pytając o zalety i wady korzystania z powyższych dwóch poleceń.

• Upewnij się, że 2222zezwalasz 0.0.0.0/0na port TCP w grupie bezpieczeństwa dla twojego nat nat
• Upewnij się, że masz poprawnie skonfigurowaną „Tablicę tras” VPC.
• Co najmniej dwie oddzielne tabele (jedna związana z prywatną podsiecią, jedna związana z publiczną podsiecią)
• Twoja 10.0.1.0(prywatna) podsieć powinna mieć regułę tablicy tras, taką jak: Miejsce 0.0.0.0/0docelowe:, Miejsce docelowe: „Nat box”
• Twoja 10.0.0.0(publiczna) podsieć powinna mieć regułę tablicy tras, taką jak: Miejsce 0.0.0.0/0docelowe:, Miejsce docelowe: „Brama internetowa”

• Upewnij się, że masz wyłączone sprawdzanie źródła / miejsca docelowego na karcie sieciowej dla twojego pola NAT, bez zabawy NATting bez tego. (Wiem, że już to masz, ale jest to naprawdę ważne, więc w przypadku niektórych przyszłych widzów)

• Upewnij się, że pakiety wychodzące wiedzą, gdzie iść:

  iptables --table nat --append POSTROUTING --source 10.0.0.0/16 --destination 0.0.0.0/0 --jump MASQUERADE

• Upewnij się, że pakiety Inboud 2222zostały poprawnie przekierowane:

  iptables --table nat --append PREROUTING --protocol tcp --dport 2222 --jump DNAT --to-destination 10.0.1.243:22

Te posty bardzo pomogły mi zrozumieć NAT AWS. Zacząłem więc badać, co sprawiło, iptables -t nat -A POSTROUTING -j MASQUERADEże zadziałało.

Cóż, odpowiedź, którą znalazłem powyżej, pozwala skrzynce NAT na źródło NAT adresu IP „LAPTOP” na „10 .0.0.54”, jednocześnie wykonując docelową translację NAT na 10.0.1.243. W tej chwili prywatne pole podsieci jest żądaniem ssh pochodzącym tylko z urządzenia NAT. To polecenie faktycznie zmniejsza bezpieczeństwo prywatnego serwera podsieci. Zaleca się użycie poniższego polecenia, aby dostroić dostęp do prywatnej podsieci za pośrednictwem ssh i NAT box, jak wspomniano poniżej;

iptables --table nat --append POSTROUTING --source "INTERNET IP of the Laptop" --destination 10.0.1.243 --jump MASQUERADE

Trochę bezpieczniej:

iptables -t nat -I PREROUTING -d 52.213.216.251 -j DNAT --to-destination 10.0.1.243:22
iptables -t nat -I POSTROUTING -s 10.0.1.243 -j SNAT --to-source 52.213.216.251