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

10

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.

wprowadź opis zdjęcia tutaj

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. )

slayedbylucifer
źródło
2
Czy wyłączyłeś sprawdzanie źródła / celu w instancji NAT?
Dusan Bajic
Co to znaczy? Jak to sprawdzić? Przeszukałem całą stronę podręcznika Iptables, ale nie mówi nic o sprawdzaniu źródła / miejsca docelowego (chyba, że ​​coś przeoczyłem).
slayedbylucifer
Musisz to zrobić w konsoli internetowej AWS (lub CLI). docs.aws.amazon.com/AmazonVPC/latest/UserGuide/…
Dusan
Dzięki. Uważam, że to już Disableddotyczy instancji NAT.
slayedbylucifer

Odpowiedzi:

8

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ń.

slayedbylucifer
źródło
Człowieku, dziękuję za milion. Miałem ten sam problem, ten sam ... Każdy krok był na miejscu ... ale było też to „-o eth0”. Usunąłem go, działało jak urok. Dzięki w milionach.
Neven
Powodem, dla którego działa, jest to, że „-s 10.0.0.0/16” mówi, że tłumaczy tylko pakiety ze źródłowym ip 10.xxx. Zgaduję, że twój domowy laptop był w sieci domowej i pochodził z zewnętrznego IP, więc NAT ignorował żądania twojego laptopa. Inni mogą chcieć uruchomić „ip r” w linii poleceń linuksa, aby sprawdzić, czy eth0 jest tak naprawdę nazwą ich urządzenia ethernetowego. Jeśli nie, zmień go na dowolną nazwę urządzenia et (np. Ens192 lub cokolwiek innego).
Ryan Shillington
Och, również nauczyłem się tego, czytając stronę podręcznika iptables. To naprawdę dobre i nie długie czytanie. Gorąco polecam. Uruchom „man iptables” z wiersza polecenia, aby zobaczyć go w pełnej krasie.
Ryan Shillington
7
  • 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

c4urself
źródło
Wszystkie Twoje sugestie są już na miejscu. Dzięki.
slayedbylucifer
1
Zaktualizowałem go, aby pokazać wszystkie etapy
sam
Dzięki. +1 za twoje wysiłki. Twoje MASQUERADEpolecenie nie jest pomocne w moim przypadku. Być może coś mi brakuje. Jedyne MASQUERADEpolecenie, które każe mi latać, to to, o którym wspomniałem w mojej odpowiedzi .
slayedbylucifer
To jest świetna rada, z wyjątkiem tego, że to nie zadziała, ponieważ routujesz tylko 10.xxx w pierwszym poleceniu iptables. Chce kierować wszystkim, co pochodzi z Internetu. Zobacz własną odpowiedź OP poniżej.
Ryan Shillington
2

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
Anirban Sinha
źródło
0

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
Alexandre MCS
źródło