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 internetskom 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 prihvaćanje paketa čiji izvor ili odredište nije njezina vlastita adresa. Ona ne govori klijentu Access Servera da pošalje internetski promet kroz tunel, ne stvara rutu prema gore i ne dodaje NAT. Mit je da je potvrdni okvir sama funkcionalnost.

Što provjera zapravo kontrolira

Svako EC2 mrežno sučelje odbacuje promet koji nije upućen njemu, osim ako instanca radi kao usmjerivač, NAT uređaj ili VPN pristupnik i vi ne isključite tu provjeru. Isključivanje daje dopuštenje za prosljeđivanje. Dopuštenje nije konfiguracija: instanci i dalje treba ruta do internetskog pristupnika ili NAT uređaja, VPC tablici ruta i dalje treba odgovarajući zapis, sigurnosne grupe i dalje moraju dopustiti tok, a poslužitelj i dalje mora prevesti ili usmjeriti povratni promet.

Provjerite trenutačnu vrijednost pomoću aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck prije nego što bilo što 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 promet usmjeri u VPN, podijeljeni ostavlja internetski promet na lokalnom putu klijenta. Spremite i primijenite kroz radni tijek proizvoda, a zatim ponovno povežite probnog klijenta, jer se politika dostavlja u trenutku povezivanja.

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

Pratite paket nakon tunela

Kad klijent pošalje internetski promet u tunel, poslužitelj ga mora proslijediti i obično prevesti. Access Server upravlja vlastitim NAT i rutirajućim pravilima, pa čitajte stvarnu konfiguraciju umjesto da dodajete pravila Community OpenVPN u generirane datoteke; neupravljana pravila prepisuju se ili se sukobljavaju pri sljedećem ažuriranju proizvoda. sudo iptables -t nat -L -n -v ili nftables ekvivalent pokazuje što se doista prevodi.

AWS strana je odvojen put. Instanca u javnoj podmreži dolazi do internetskog pristupnika izravno 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 internetskog pristupnika. Priključivanje internetskog 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 zataji.

Provjerite tablicu ruta povezanu s podmrežom instance, ne samo glavnu tablicu VPC-a. Povezivanja podmreža nadjačavaju glavnu tablicu, a zastarjelo povezivanje čest je razlog zaš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 zataje, 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.

Usporedite vraćenu adresu s izlazom koji ste namjeravali. Ako je to javna adresa instance, promet 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 jest da preglednik na poslužitelju dokazuje prosljeđivanje za klijenta.

Ne dopustite 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 stoga može nastaviti koristiti lokalni IPv6 put dok je IPv4 u tunelu. Testirajte obitelj adresa do koje vam je doista stalo i izričito odlučite treba li drugu isključiti.

Naposljetku testirajte nepovezano stanje. Izbor punog tunela opisuje politiku usmjeravanja dok ste povezani, a ne što se događa kad tunel padne. Ako je zahtjev da nijedan promet ne pobjegne izvan VPN-a, to je pitanje kill-switcha i vatrozida i traži vlastiti test, a ne zaključak iz tablice ruta.