Tuneli i plotë i Access Server në EC2: pse një kuti kontrolli nuk mjafton

Çaktivizimi i kontrollit të burimit dhe destinacionit në një instancë EC2 është përgjigjja më e përsëritur për pyetjet rreth daljes në internet të Access Server dhe në vetvete nuk bën asgjë për klientët tuaj. Kontrolli është një kufizim përcjelljeje i AWS: bën që instanca të pranojë paketa burimi ose destinacioni i të cilave nuk është adresa e saj. Nuk i thotë klientit të Access Server të dërgojë trafikun e internetit përmes tunelit, nuk krijon një rrugë lart dhe nuk shton NAT. Miti është se kutia e kontrollit është vetë funksioni.

Çfarë kontrollon vërtet kontrolli

Çdo ndërfaqe rrjeti e EC2 hedh poshtë trafikun që nuk i drejtohet asaj, përveç nëse instanca vepron si router, pajisje NAT ose portë VPN dhe ju çaktivizoni atë kontroll. Çaktivizimi jep leje për të përcjellë. Leja nuk është konfigurim: instanca ka ende nevojë për një rrugë drejt një porte interneti ose pajisjeje NAT, tabela e rrugëve të VPC ka ende nevojë për hyrjen përkatëse, grupet e sigurisë duhet ende të lejojnë rrjedhën, dhe serveri duhet ende të përkthejë ose të rrugëzojë trafikun e kthimit.

Kontrolloni vlerën aktuale me aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck përpara se të ndryshoni diçka. Nëse e ndryshoni në konsolë, ndryshojeni sepse instanca përcjell për të tjerët, jo sepse një klient nuk arrin internetin.

Politika e rrugëzimit të klientit i takon Access Server

Në Access Server 3, hapni Access Controls dhe gjeni seksionin Internet Access and DNS. Zgjedhja Internet Gateway ofron tunel të plotë ose të ndarë; tuneli i plotë i thotë klientit të rrugëzojë trafikun e tij të parazgjedhur brenda VPN, tuneli i ndarë e lë trafikun e internetit në rrugën lokale të klientit. Ruani dhe aplikoni përmes rrjedhës së punës së produktit, më pas rilidhni një klient testimi, sepse politika dorëzohet në momentin e lidhjes.

Versionet e vjetra përdorin menu të tjera dhe disa ndërtime Community të OpenVPN nuk kanë kontroll ekuivalent. Kontrolloni versionin kryesor të instaluar përpara se të kërkoni një ekran që nuk ekziston. Më pas konfirmoni çfarë mori klienti: një profil tuneli të plotë duhet të instalojë një rrugë të parazgjedhur përmes tunelit, dhe një profil tuneli të ndarë nuk duhet ta bëjë këtë.

Ndiqni paketën pas tunelit

Pasi klienti dërgon trafikun e internetit në tunel, serveri duhet ta përcjellë dhe zakonisht ta përkthejë. Access Server menaxhon rregullat e veta të NAT dhe të rrugëzimit, prandaj lexoni konfigurimin efektiv në vend që të shtoni rregulla Community OpenVPN në skedarët e gjeneruar; rregullat e pamenaxhuara mbishkruhen ose bien ndesh në përditësimin tjetër të produktit. sudo iptables -t nat -L -n -v ose ekuivalenti në nftables tregon çfarë po përkthehet vërtet.

Ana e AWS është një rrugë e veçantë. Një instancë në një nënrrjet publik arrin një portë interneti drejtpërdrejt dhe mban adresën e saj publike ose IP-në elastike. Një instancë në një nënrrjet privat ka nevojë për një rrugë drejt një porte NAT ose instance NAT, dhe pajisja NAT ka nevojë për rrugën e saj drejt portës së internetit. Lidhja e një porte interneti me VPC nuk i jep vetvetiu asnjë burimi privat një adresë kthimi publike, prandaj i njëjti konfigurim Access Server funksionon në një nënrrjet dhe dështon në heshtje në një tjetër.

Kontrolloni tabelën e rrugëve të lidhur me nënrrjetin e instancës, jo vetëm tabelën kryesore të VPC. Lidhjet e nënrrjeteve mbizotërojnë mbi tabelën kryesore, dhe një lidhje e vjetëruar është një shkak i zakonshëm që një konfigurim funksional të ndalet pas një rindërtimi.

Mbani të ndara daljen IP dhe DNS

Testoni fillimisht një literal adrese, pastaj një emër, nga i njëjti aplikacion klienti. Nëse curl -4 https://checkip.amazonaws.com kthen një adresë publike por emrat e hosteve dështojnë, tuneli dhe rruga NAT funksionojnë dhe problemi është DNS: zgjidhësi i dërguar, gjendja e zgjidhësit të klientit, ose një grup sigurie që bllokon zgjidhësin. Cilësimet DNS të Access Server ndodhen në të njëjtën zonë Internet Access, por ato udhëtojnë në një rrugë kodi tjetër.

Krahasoni adresën e kthyer me daljen që kishit ndërmend. Nëse është adresa publike e instancës, trafiku përkthehet nga instanca; nëse është adresë e portës NAT, përdoret rruga e nënrrjetit privat. Të dyja mund të jenë të sakta. Ajo që nuk mund të përfundoni është se një shfletues në server provon përcjelljen për klientin.

Mos lejoni që një kuti të mbyllë hetimin

IPv6 është një vendim i veçantë. Një politikë tuneli të plotë për IPv4 nuk thotë asgjë nëse IPv6 transportohet, bllokohet ose rrjedh, dhe një klient me dy shtresa mund të vazhdojë të përdorë rrugën e tij lokale IPv6 ndërsa IPv4 është në tunel. Testoni familjen e adresave që ju intereson vërtet dhe vendosni shprehimisht nëse tjetra duhet të çaktivizohet.

Së fundmi, testoni gjendjen e shkëputur. Zgjedhja e tunelit të plotë përshkruan politikën e rrugëzimit gjatë lidhjes, jo çfarë ndodh kur tuneli bie. Nëse kërkesa është që asnjë trafik të mos shpëtojë jashtë VPN, kjo është çështje kill-switch dhe muri i zjarrit, dhe kërkon testin e vet në vend të një përfundimi nga tabela e rrugëve.