Tunnel kamili ya Access Server kwenye EC2: kwa nini kisanduku kimoja cha kuteua hakitoshi

Kuzima ukaguzi wa chanzo na lengwa kwenye kifaa cha EC2 ni jibu linalorudiwa zaidi kuhusu utokeaji wa intaneti wa Access Server, na peke yake hakifanyi chochote kwa wateja wako. Ukaguzi ni kikwazo cha upelekaji cha AWS: hufanya kifaa kikubali pakiti ambazo chanzo au lengo si anwani yake mwenyewe. Hauriambii mteja wa Access Server kutuma trafiki ya intaneti kupitia tunnel, haukiundi njia ya kwenda juu na haukuongezi NAT. Hadithi ni kwamba kisanduku cha kuteua ndiyo kipengele chenyewe.

Ukaguzi unadhibiti nini kwa kweli

Kila kiolesura cha mtandao cha EC2 hutupa trafiki isiyoelekezwa kwake, isipokuwa kifaa kinafanya kazi kama kipanga njia, kifaa cha NAT au lango la VPN na umesitisha ukaguzi huo. Kuusitisha kunatoa ruhusa ya kupeleka. Ruhusa si usanidi: kifaa bado kinahitaji njia kuelekea lango la intaneti au kifaa cha NAT, jedwali la njia la VPC bado linahitaji ingizo linalolingana, vikundi vya usalama bado lazima viruhusu mtiririko, na seva bado lazima itafsiri au ielekeze trafiki inayorudi.

Kagua thamani ya sasa kwa aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck kabla ya kubadilisha chochote. Ukibadilisha kwenye konsoli, ibadilishe kwa sababu kifaa kinapeleka kwa ajili ya wengine, si kwa sababu mteja hafiki intaneti.

Sera ya njia ya mteja inamilikiwa na Access Server

Katika Access Server 3, fungua Access Controls na upate sehemu ya Internet Access and DNS. Uchaguzi wa Internet Gateway unatoa tunnel kamili au tunnel iliyogawanywa; tunnel kamili humwambia mteja aelekeze trafiki yake ya kawaida ndani ya VPN, tunnel iliyogawanywa huacha trafiki ya intaneti kwenye njia ya ndani ya mteja. Hifadhi na tumia kupitia mtiririko wa kazi wa bidhaa, kisha unganisha tena mteja wa majaribio, kwa sababu sera huwasilishwa wakati wa muunganisho.

Matoleo ya zamani hutumia menyu tofauti na baadhi ya miundo ya Community OpenVPN haina udhibiti sawa. Kagua toleo kuu lililowekwa kabla ya kutafuta skrini isiyopo. Kisha thibitisha kile mteja alipokea: wasifu wa tunnel kamili unapaswa kuweka njia ya kawaida kupitia tunnel, na wasifu wa tunnel iliyogawanywa haupaswi kufanya hivyo.

Fuata pakiti baada ya tunnel

Mteja anapotuma trafiki ya intaneti kwenye tunnel, seva lazima iipeleke na kwa kawaida iitafsiri. Access Server husimamia kanuni zake za NAT na njia, kwa hiyo soma usanidi unaofanya kazi badala ya kuongeza kanuni za Community OpenVPN kwenye faili zilizozalishwa; kanuni zisizosimamiwa hufutwa au kugongana katika sasisho la bidhaa linalofuata. sudo iptables -t nat -L -n -v au kifananishi cha nftables kinaonyesha kinachotafsiriwa kwa kweli.

Upande wa AWS ni njia tofauti. Kifaa kilicho kwenye subnet ya umma hufikia lango la intaneti moja kwa moja na huhifadhi anwani yake ya umma au IP inayobadilika. Kifaa kilicho kwenye subnet ya kibinafsi kinahitaji njia kuelekea lango la NAT au kifaa cha NAT, na kifaa cha NAT kinahitaji njia yake kuelekea lango la intaneti. Kuunganisha lango la intaneti kwenye VPC peke yake hakupi chanzo chochote cha kibinafsi anwani ya kurudi ya umma, ndiyo sababu usanidi huo huo wa Access Server hufanya kazi kwenye subnet moja na kushindwa kimyakimya kwenye nyingine.

Kagua jedwali la njia linalohusiana na subnet ya kifaa, si jedwali kuu la VPC peke yake. Uhusiano wa subnet hushinda jedwali kuu, na uhusiano wa zamani ni sababu ya kawaida ya usanidi uliokuwa ukifanya kazi kusimama baada ya kujengwa upya.

Tenganisha utokeaji wa IP na DNS

Jaribu kwanza anwani halisi, kisha jina, kutoka programu hiyo hiyo ya mteja. Ikiwa curl -4 https://checkip.amazonaws.com inarudisha anwani ya umma lakini majina ya mwenyeji yanashindwa, tunnel na njia ya NAT zinafanya kazi na tatizo ni DNS: kisuluhishi kilichosukumwa, hali ya kisuluhishi cha mteja, au kikundi cha usalama kinachozuia kisuluhishi. Mipangilio ya DNS ya Access Server iko katika eneo hilo hilo la Internet Access, lakini husafiri kwa njia tofauti ya msimbo.

Linganisha anwani iliyorudishwa na utokeaji uliokusudia. Ikiwa ni anwani ya umma ya kifaa, trafiki inatafsiriwa na kifaa; ikiwa ni anwani ya lango la NAT, njia ya subnet ya kibinafsi inatumika. Zote mbili zinaweza kuwa sahihi. Usichoweza kuhitimisha ni kwamba kivinjari kwenye seva kinathibitisha upelekaji kwa mteja.

Usiruhusu kisanduku kimoja kifunge uchunguzi

IPv6 ni uamuzi tofauti. Sera ya tunnel kamili kwa IPv4 haisemi chochote kuhusu kama IPv6 inabebwa, imezuiwa au inavuja, na mteja mwenye tabaka mbili anaweza kuendelea kutumia njia yake ya ndani ya IPv6 wakati IPv4 iko kwenye tunnel. Jaribu familia ya anwani unayojali kwa kweli, na amua waziwazi kama nyingine inapaswa kuzimwa.

Mwisho, jaribu hali ya kukatika. Uchaguzi wa tunnel kamili unaelezea sera ya njia ukiwa umeunganishwa, si kile kinachotokea tunnel inapoanguka. Ikiwa hitaji ni kwamba trafiki yoyote isitoroke nje ya VPN, hilo ni swali la kill-switch na ukuta wa moto, na linahitaji jaribio lake mwenyewe badala ya hitimisho kutoka jedwali la njia.