Puni tunel Access Servera na EC2: zašto jedan potvrdni okvir nije dovoljan

Isključivanje provjere izvora i odredišta na EC2 instanci najčešće je ponavljan odgovor na pitanja o internet izlazu Access Servera i samo po sebi ne čini ništa za vaše klijente. Provjera je AWS ograničenje prosljeđivanja: omogućuje instanci da prihvati pakete čiji izvor ili odredište nije njena vlastita adresa. Ona ne govori klijentu Access Servera da pošalje internet saobraćaj kroz tunel, ne stvara rutu prema gore i ne dodaje NAT. Mit je da je potvrdni okvir sama funkcija.

Šta provjera zapravo kontroliše

Svako EC2 mrežno sučelje odbacuje saobraćaj koji nije upućen njemu, osim ako instanca radi kao ruter, NAT uređaj ili VPN pristupnik i vi ne isključite tu provjeru. Isključivanje daje dozvolu za prosljeđivanje. Dozvola nije konfiguracija: instanci i dalje treba ruta do internet pristupnika ili NAT uređaja, VPC tabeli ruta i dalje treba odgovarajući zapis, sigurnosne grupe i dalje moraju dozvoliti tok, a server i dalje mora prevesti ili usmjeriti povratni saobraćaj.

Provjerite trenutnu vrijednost pomoću aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck prije nego što bilo šta promijenite. Ako je promijenite u konzoli, promijenite je zato što instanca prosljeđuje za druge, a ne zato što klijent ne može doći na internet.

Politika usmjeravanja klijenta pripada Access Serveru

U Access Serveru 3 otvorite Access Controls i pronađite odjeljak Internet Access and DNS. Izbor Internet Gateway nudi puni ili podijeljeni tunel; puni tunel govori klijentu da svoj zadani saobraćaj usmjeri u VPN, podijeljeni ostavlja internet saobraćaj na lokalnom putu klijenta. Sačuvajte i primijenite kroz radni tok proizvoda, pa ponovo povežite probnog klijenta, jer se politika dostavlja u trenutku povezivanja.

Starija izdanja koriste drugačije menije, a neke Community OpenVPN verzije nemaju ekvivalentnu kontrolu. Provjerite instaliranu glavnu verziju prije nego što tražite ekran koji ne postoji. Zatim potvrdite šta je klijent dobio: profil punog tunela treba instalirati zadanu rutu kroz tunel, a profil podijeljenog tunela to ne treba.

Pratite paket nakon tunela

Kada klijent pošalje internet saobraćaj u tunel, server ga mora proslijediti i obično prevesti. Access Server upravlja vlastitim NAT i rutirajućim pravilima, pa čitajte stvarnu konfiguraciju umjesto da dodajete Community OpenVPN pravila u generisane datoteke; neupravljana pravila se prepisuju ili sukobljavaju pri sljedećem ažuriranju proizvoda. sudo iptables -t nat -L -n -v ili nftables ekvivalent pokazuje šta se zaista prevodi.

AWS strana je odvojen put. Instanca u javnoj podmreži dolazi do internet pristupnika direktno i zadržava svoju javnu adresu ili elastic IP. Instanci u privatnoj podmreži treba ruta do NAT pristupnika ili NAT instance, a NAT uređaju treba vlastita ruta do internet pristupnika. Priključivanje internet pristupnika na VPC samo po sebi ne daje nijednom privatnom izvoru javnu povratnu adresu, zato ista Access Server postavka radi u jednoj podmreži, a u drugoj tiho pada.

Provjerite tabelu ruta povezanu s podmrežom instance, ne samo glavnu tabelu VPC-a. Povezivanja podmreža nadjačavaju glavnu tabelu, a zastarjelo povezivanje čest je razlog što radna konfiguracija stane nakon ponovne izgradnje.

Držite IP izlaz i DNS odvojeno

Testirajte prvo literal adrese, zatim ime, iz iste klijentske aplikacije. Ako curl -4 https://checkip.amazonaws.com vrati javnu adresu, ali imena hostova ne rade, tunel i NAT put rade, a problem je u DNS-u: poslani resolver, stanje resolvera na klijentu ili sigurnosna grupa koja blokira resolver. DNS postavke Access Servera nalaze se u istom Internet Access području, ali idu drugim putem kroz kod.

Uporedite vraćenu adresu s izlazom koji ste namjeravali. Ako je to javna adresa instance, saobraćaj prevodi instanca; ako je adresa NAT pristupnika, koristi se put privatne podmreže. Oboje može biti ispravno. Ono što ne možete zaključiti jeste da preglednik na serveru dokazuje prosljeđivanje za klijenta.

Ne dozvolite da jedan okvir zatvori istragu

IPv6 je odvojena odluka. Politika punog tunela za IPv4 ne govori ništa o tome prenosi li se IPv6, blokira ili curi, a klijent s dva steka može nastaviti koristiti lokalni IPv6 put dok je IPv4 u tunelu. Testirajte porodicu adresa do koje vam je zaista stalo i izričito odlučite treba li drugu isključiti.

Na kraju testirajte nepovezano stanje. Izbor punog tunela opisuje politiku usmjeravanja dok ste povezani, a ne šta se dešava kad tunel padne. Ako je zahtjev da nijedan saobraćaj ne pobjegne izvan VPN-a, to je pitanje kill-switcha i vatrozida i traži vlastiti test, a ne zaključak iz tabele ruta.