AWS Client VPN i lidhur, por pa internet: kontrolli i rrugëve

Jeni të lidhur me pikën fundore të AWS Client VPN, nënrrjeti privat përgjigjet, dhe megjithatë çdo faqe publike përfundon me skadim kohe. Ky kombinim e ngushton problemin në një nga tre objektet në anën e menaxhuar: rruga që instalon klienti, rruga e pikës fundore bashkë me rregullën e saj të autorizimit, ose kërcimi tjetër i nënrrjetit të lidhur. I kontrolloj në atë rend, sepse çdo dështim duket ndryshe nga ana e klientit. Ky udhëzues mbulon pikën fundore të menaxhuar të lidhur me VPC, jo një server OpenVPN në një instancë EC2 dhe jo një lidhje Cloud WAN ose Transit Gateway.

Filloni me atë që klienti rrugëton vërtet

Gjendja e lidhur provon sesionin TLS dhe caktimin e CIDR klientit, asgjë më shumë. Pyetni sistemin operativ se ku do të shkonte një adresë publike ndërsa tuneli është aktiv. Në Linux, ip route get 1.1.1.1 duhet të emërtojë ndërfaqen e tunelit; në macOS, netstat -rn -f inet | head -5 tregon shënimin e parazgjedhur; në Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 shtyp ndërfaqen e zgjedhur dhe kërcimin tjetër.

Më pas lexoni flamurin e tunelit të ndarë, sepse ai vendos nëse rrugët e publikuara nga pika fundore janë të vetmet destinacione që klienti dërgon në tunel:

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

Kur SplitTunnel është true, një destinacion publik e përdor tunelin vetëm kur pika fundore publikon një rrugë që e mbulon, pra një 0.0.0.0/0 që mungon e lë atë trafik në ndërfaqen lokale. Kur është false, klienti e kap trafikun, por pika fundore duhet ende ta rrugëtojë dhe ta autorizojë; përndryshe paketat hyjnë në tunel dhe ndalen aty. Rilidhni klientin pas ndryshimit të njërës prej dy cilësimeve, sepse rrugët dhe serverët DNS dorëzohen në momentin e lidhjes dhe një klient në punë mund të mbajë grupin e vjetër.

Lexoni rrugën e pikës fundore dhe rregullën e autorizimit veçmas

Këto janë dy objekte, dhe krijimi i njërit nuk krijon tjetrin. Listoni rrugët e pikës fundore dhe kërkoni një rrugë të parazgjedhur, objektivi i së cilës është një nënrrjet i lidhur:

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

Çdo rrugë ka saktësisht një nënrrjet objektiv, prandaj tre lidhje kanë nevojë për një rrugë të parazgjedhur përkatëse secila. AWS e dokumenton këtë kërkesë mbulimi, dhe simptoma praktike e një boshllëku është një përdorues që punon nga një nënrrjet dhe ngec nga një tjetër, që lexohet si defekt i herëpashershëm në vend të një rruge që mungon. Dokumentacioni zyrtar i skenarit të Client VPN përshkruan rregullimin me nënrrjet publik të cilit i përkasin këto rrugë.

Autorizimi është objekti i dytë. Kur asnjë rregull nuk e mbulon destinacionin publik, tuneli e mbart paketën dhe shërbimi e hedh, pra burimet private vazhdojnë të punojnë, ndërsa interneti jo:

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

Një rregull për CIDR-in e VPC nuk thotë asgjë për 0.0.0.0/0. Shtimi i pjesëve që mungojnë për një tunel të plotë do të thotë një rrugë për çdo nënrrjet të lidhur plus një rregull autorizimi që mund ta auditoni më vonë:

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 i jep destinacionin çdo klienti të pikës fundore, prandaj mbajeni vetëm sa kohë tuneli duhet të jetë i plotë; një rregull i lidhur me një grup drejtorie është i preferueshëm kur keni grupe për të lidhur.

Ndiqni paketën jashtë nënrrjetit të lidhur

Rruga e pikës fundore vendos që AWS ia dorëzon paketën atij nënrrjeti. Ajo nuk vendos kërcimin tjetër pas tij, i cili jeton në tabelën e vetë rrugëve VPC të nënrrjetit:

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

Një rrugë e parazgjedhur e përdorshme tregon drejt një porte interneti për një nënrrjet publik, ose drejt një porte NAT për një privat, dhe gjendja blackhole do të thotë që objektivi është fshirë dhe shtegu tani vdes në heshtje. Këto janë tabela të ndryshme nga lista e rrugëve të pikës fundore, dhe rregullimi i njërës nuk rregullon tjetrën.

Në këtë kërcim rrinë dy filtra. Grupi i sigurisë i aplikuar në lidhjen e rrjetit objektiv duhet të lejojë trafikun dalës drejt destinacionit publik, dhe çdo ACL rrjeti i zbatueshëm duhet të lejojë kërkesën dhe trafikun e kthimit në porta efemere. Një grup sigurie lidhjeje kufizues është një shkak i zakonshëm që aksesi privat punon ndërsa ai publik jo.

Zgjidhni shtresën e parë sipas simptomës, në vend që të ndryshoni të treja njëherësh:

Ndani dështimin e DNS nga një rrugë e vdekur

Zgjidhja e emrave dështon ndryshe nga përcjellja, dhe tuneli i plotë e bën këtë dallim të rëndësishëm, sepse resolueri i shtyrë tani arrihet përmes tunelit. Nëse pika fundore specifikon serverë DNS të VPC-së, adresat e tyre kanë nevojë për mbulim rruge dhe autorizim si çdo destinacion tjetër. Pyetni resoluerin drejtpërdrejt për të parë çfarë dështimi keni: dig +short example.com @10.0.0.2, ose nslookup example.com 10.0.0.2 në Windows.

Kur një URL numerike përgjigjet dhe një me emër jo, ndaloni së redaktuarit rrugën e parazgjedhur dhe punoni me DNS. Një kërkesë drejt një adrese IP nuk provon asgjë për një host virtual me emër dhe certifikatën e tij, prandaj mbani një provë me emër në kontrollin përfundimtar.

Koha ndihmon. Një lidhje TCP që nuk merr përgjigje brenda pak sekondash tregon rrugëtim ose një filtër, ndërsa një kërkesë që rri varur brenda kërkimit të emrit tregon resoluerin. Ndryshimi i rrugës së parazgjedhur ndërsa resolueri është i paarritshëm zakonisht e kthen një dështim në dy.

Kthejini mbrapsht pastër, më pas verifikoni shtegun e daljes

Të dy objektet ishin shtesë, prandaj kthimi mbrapsht është fshirje dhe jo rregullim:

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

Rilidhuni dhe konfirmoni nëpër cilin shteg trafiku del. Krahasoni adresën publike të vëzhguar me adresën IP elastike të portës NAT, ose me portën e internetit që kishit ndërmend të përdorni, dhe kontrolloni nëse një burim privat përgjigjet ende në të njëjtin sesion.

Përfundoni me një listë të shkurtër dhe trajtojeni pikën e fundit si pjesë e ndryshimit dhe jo si dokumentacion:

• Një 0.0.0.0/0 rrugë e pikës fundore për çdo nënrrjet të lidhur.
• Një rregull autorizimi që mbulon 0.0.0.0/0 për klientët që dëshironi të shërbeni.
• Një rrugë e parazgjedhur VPC që nuk është në gjendjen blackhole në çdo nënrrjet të lidhur.
• Dalja e grupit të sigurisë së lidhjes, plus trafiku i kthimit i ACL-së.
• Adresat e resoluerit të rrugëtuara dhe të autorizuara, të verifikuara me kërkesë me emër.
• Një kthim mbrapsht i regjistruar për rrugën dhe rregullën.

Një shënim për shtrirjen: ky është një shteg IPv4. Një klient me stivë të dyfishtë mban lidhshmërinë IPv6 që e ka tashmë, prandaj një rrugë e parazgjedhur IPv6 është vendim i veçantë me autorizimin e vet dhe jo efekt anësor i këtij.