AWS Client VPN konektatuta baina internetik ez: ibilbideen egiaztapena

AWS Client VPN amaierako puntura konektatuta zaude, azpisare pribatuak erantzuten du, eta oraindik ere orrialde publiko guztiek denbora-muga gainditzen dute. Konbinazio horrek arazoa kudeatutako aldeko hiru objektuetako batera murrizten du: bezeroak instalatzen duen ibilbidea, amaierako puntuaren ibilbidea bere baimen-arauarekin batera, edo lotutako azpisarearen hurrengo jauzia. Hori horrela egiaztatzen ditut, bezeroaren ikuspegitik hutsegite bakoitza desberdin ikusten delako. Gida honek VPC-rekin lotutako amaierako puntu kudeatua hartzen du, ez EC2 instantzia bateko OpenVPN zerbitzaria eta ez Cloud WAN edo Transit Gateway konexioa.

Hasi bezeroak benetan bideratzen duenarekin

Konektatuta egoteak TLS saioa eta bezeroari CIDR esleipena frogatzen ditu, beste ezer ez. Galdetu sistema eragileari norantz joango litzatekeen helbide publiko bat tunela aktibo dagoen bitartean. Linuxen, ip route get 1.1.1.1 tunelaren interfazea izendatu beharko luke; macOSen, netstat -rn -f inet | head -5 lehenetsitako sarrera erakusten du; Windowsen, Find-NetRoute -RemoteIPAddress 1.1.1.1 aukeratutako interfazea eta hurrengo jauzia inprimatzen ditu.

Ondoren irakurri split-tunnel bandera, amaierako puntuak argitaratutako ibilbideak bezeroak tunelera bidaltzen dituen helmuga bakarrak diren erabakitzen baitu:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Noiz SplitTunnel true bada, helmuga publiko batek tunela erabiltzen du amaierako puntuak hura estaltzen duen ibilbidea argitaratzen duenean soilik, beraz falta den 0.0.0.0/0 batek trafiko hori interfaze lokalean uzten du. False bada, bezeroak trafikoa harrapatzen du, baina amaierako puntuak oraindik bideratu eta baimendu behar du; bestela paketeak tunelera sartzen dira eta han gelditzen dira. Berriz konektatu bezeroa bi ezarpenetako bat aldatu ondoren, ibilbideak eta DNS zerbitzariak konektatzean entregatzen baitira eta martxan dagoen bezeroak aurreko multzoa gorde baitezake.

Irakurri amaierako puntuaren ibilbidea eta baimen-araua bereizita

Bi objektu dira, eta bat sortzeak ez du bestea sortzen. Zerrendatu amaierako puntuaren ibilbideak eta bilatu helburua lotutako azpisarea duen ibilbide lehenetsia:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Ibilbide bakoitzak azpisare helburu zehatz bat du, beraz hiru loturak dagokion ibilbide lehenetsia behar dute bakoitzak. AWSk estaldura-baldintza hori dokumentatzen du, eta hutsune baten sintoma praktikoa azpisare batetik lan egiten duen eta bestetik trabatzen den erabiltzailea da, eta hori noizean behingo akats gisa irakurtzen da, falta den ibilbide gisa beharrean. Client VPN eszenarioaren dokumentazio ofizialak ibilbide hauek dagozkien azpisare publikoaren antolaketa deskribatzen du.

Baimena da bigarren objektua. Helmuga publikoa estaltzen duen araurik ez badago, tunelek paketea eramaten du eta zerbitzuak baztertu egiten du, beraz baliabide pribatuek funtzionatzen jarraitzen dute internetek ez bezala:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

VPC CIDRrako arau batek ez du ezer esaten 0.0.0.0/0 buruz. Tunel oso baterako falta diren piezak gehitzeak lotutako azpisare bakoitzeko ibilbide bat esan nahi du, gehi geroago auditoria dezakezun baimen-arau bat:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all amaierako puntuaren bezero guztiei ematen die helmuga, beraz mantendu tunel osoa izan behar den bitartean soilik; direktorio-talde bati lotutako araua hobea da lotzeko taldeak dituzunean.

Jarraitu paketeari lotutako azpisaretik kanpora

Amaierako puntuaren ibilbideak erabakitzen du AWSk paketea azpisare horri ematen diola. Ez du erabakitzen hortik aurrera dagoen hurrengo jauzia, azpisarearen beraren VPC ibilbide-taulan bizi dena:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Erabil daitekeen ibilbide lehenetsi batek interneteko atea seinalatzen du azpisare publikorako, edo NAT atea pribatu baterako, eta blackhole egoerak helburua ezabatu dela eta bideak orain isilki hiltzen duela esan nahi du. Amaierako puntuaren ibilbide-zerrendatik desberdinak diren taulek dira, eta bat konpontzeak ez du bestea konpontzen.

Jauzi honetan bi iragazki daude. Helburuko sare-loturari aplikatutako segurtasun-taldeak helmuga publikorantz irteerako trafikoa baimendu behar du, eta aplikagarri den sareko ACLak eskaera eta itzulera-trafikoa baimendu behar ditu portu efimeroetan. Loturaren segurtasun-talde murriztailea ohiko arrazoia da sarbide pribatuak funtzionatzeko eta publikoak ez.

Hautatu lehen geruza sintomaren arabera, hirurak aldi berean aldatu beharrean:

Bereizi DNS hutsegitea ibilbide hiletik

Izen-ebazpenak beste modu batera huts egiten du birbidaltzeak baino, eta tunel osoak diferentzia garrantzitsua egiten du bultzatutako ebazlea orain tuneletik iristen delako. Amaierako puntuak VPCko DNS zerbitzariak zehazten baditu, haien helbideek ibilbide-estaldura eta baimena behar dituzte beste edozein helmugak bezala. Galdetu ebazleari zuzenean zein hutsegite duzun ikusteko: dig +short example.com @10.0.0.2, edo nslookup example.com 10.0.0.2 Windowsen.

URL zenbakitzaile batek erantzuten duenean eta izeneko batek ez, utzi ibilbide lehenetsia editatzeari eta lan egin DNSan. IP helbide baterako eskaerak ez du ezer frogatzen izeneko ostalari birtual bati eta haren ziurtagiriari buruz, beraz gorde izeneko proba bat azken egiaztapenean.

Denborak laguntzen du. Segundo batzuetan erantzunik jasotzen ez duen TCP konexioak bideratzean edo iragazkian jartzen du arreta, eta izen-bilaketan zintzilik geratzen den eskaerak ebazlean. Ibilbide lehenetsia ebazlea iristezina den bitartean aldatzeak hutsegite bat bihurtzen du normalean bi.

Itzuli garbi eta gero egiaztatu irteera-bidea

Bi objektuak gehigarriak ziren, beraz itzultzea ezabatzea da, ez konpontzea:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Berriz konektatu eta egiaztatu zein bidetik ateratzen den trafikoa. Alderatu ikusitako helbide publikoa NAT atearen IP helbide elastikoarekin edo erabili nahi zenuen interneteko atearekin, eta egiaztatu baliabide pribatu batek oraindik erantzuten duela saio berean.

Amaitu zerrenda labur batekin eta tratau azken elementua aldaketaren parte gisa, dokumentazio gisa beharrean:

• Bat 0.0.0.0/0 amaierako puntuaren ibilbidea lotutako azpisare bakoitzeko.
• Baimen-arau bat 0.0.0.0/0 estaltzen duena zerbitzatu nahi dituzun bezeroentzat.
• VPC ibilbide lehenetsi bat blackhole egoeran ez dagoena lotutako azpisare bakoitzean.
• Loturaren segurtasun-taldearen irteera, gehi ACL itzulera-trafikoa.
• Ebazlearen helbideak bideratuta eta baimenduta, izeneko eskaera batekin egiaztatuta.
• Ibilbidearen eta arauaren itzultze erregistratua.

Kapsadura-ohar bat: hau IPv4 bidea da. Dual-stack bezero batek jadanik duen IPv6 konektibitatea gordetzen du, beraz IPv6 ibilbide lehenetsia erabaki bereizia da, bere baimenarekin, eta ez honen albo-ondorioa.