DNS i pikës fundore të AWS Client VPN: pse dështon fiksimi i IP-së të zgjidhur

Javën e kaluar dig +short ju dha një adresë për emrin e pikës fundore në profilin tuaj të AWS Client VPN, dhe tuneli u lidh. Këtë javë i njëjti profil qëndron në 'Connecting' në laptopin tuaj, ndërsa kopja e paprekur e një kolegu ende funksionon. Asgjë nuk u bllokua dhe certifikata nuk skadoi. Dikush zëvendësoi emrin e hostit të pikës fundore me atë adresë të zgjidhur, dhe shërbimi nuk përgjigjet më atje. Emri i eksportuar është pjesa e ndërtuar për t'i mbijetuar asaj ndryshimi.

Emri në profilin tuaj mund të mos jetë emri që kërkohet

Profilet e eksportuara nga Client VPN zakonisht mbajnë remote-random-hostname. Kur ajo opsion është aktiv, klienti ndërton një etiketë njëpërdorimëshe, e bashkon me emrin e pikës fundore me një pikë dhe zgjidh emrin e kombinuar. Një regjistrim wildcard në zonën e pikës fundore përgjigjet për çdo etiketë, prandaj një prefiks i shpikur zgjidhet ende dhe prandaj truku mbetet i padukshëm kur përpiqeni ta riprodhoni pyetjen me dorë.

Pra, kur ngjitni emrin e pikës fundore në një terminal dhe merrni një përgjigje, keni zgjidhur një emër tjetër nga ai që klienti përdor gjatë lidhjes. Ky mospërputhje nuk është defekt që duhet korrigjuar në profil. Etiketa rigjenerohet me qëllim: opsioni i pengon cache-t të mbajnë një përgjigje të vjetruar dhe nuk identifikon kurrë makinën ose sesionin tuaj.

Kam hasur në rastin e përputhshmërisë ku një klient e injoron opsionin plotësisht. AWS dokumenton zgjidhjen: mbani emrin e vërtetë të pikës fundore dhe shtoni përpara një varg të rastësishëm plus një pikë, duke e trajtuar si një model emërtimi dhe jo si një vlerë për t'u ngjitur. Zbatimi i kësaj te një klient i vjetër është i arsyeshëm; kodimi i vargut me prefiks si pikë fundore nuk është.

Pse një përgjigje e ruajtur nuk mund të mbetet e saktë

Adresat e pikës fundore të Client VPN menaxhohen nga AWS dhe ndryshojnë me kalimin e kohës, gjë që dokumentacioni i praktikave më të mira e thotë hapur. Një përgjigje e kapur është një fotografi e një zgjidhjeje. Një profil që e kodon atë bëhet profil i drejtuar drejt një hosti të çaktivizuar sapo shërbimi lëviz, dhe dështimi rrallë duket si DNS: merrni një skadim kohe lidhjeje ose një handshake të ngecur, kështu që njerëzit ndjekin routing-un dhe certifikatat.

E njëjta përgjigje në /etc/hosts trashëgon të njëjtin afat me një problem shtesë. Një zë hosts i mbijeton rindezjeve, ri-eksporteve dhe rregullimeve 'riinstalo klientin', kështu që dështimi kthehet sa herë që adresa lëviz. Kam parë një të qëndrojë javë të tëra pa dëm dhe pastaj të nxjerrë jashtë loje çdo makinë që e mbante, ndërsa instalo të reja lidheshin normalisht. Ky ndarje, një grup dështon dhe një tjetër është mirë në të njëjtin llogari, është gjurma më e lirë që do të merrni.

Kufizoni saktë shtrirjen e rastësishtimit. Ai ndodh për çdo provë lidhjeje. Një tunel i vendosur nuk e zgjidh sërish pikën e vet fundore, nuk ndërron server në mes të sesionit, dhe kërkesat individuale të aplikacioneve nuk zgjedhin secila një host të ri VPN. Vetëm prova tjetër zgjidh sërish, prandaj një sesion që punon gjithë pasditen nuk thotë asgjë për nesër në mëngjes.

Çfarë kontrollon shërbimi kur ngrihet tuneli

Client VPN kërkon që adresa me të cilën jeni lidhur të përputhet me një adresë të zgjidhur për emrin DNS të pikës fundore. Kjo kërkesë e vetme shpjegon disa dështime që duken të palidhura: një regjistrim DNS i personalizuar që tregon diku tjetër, një frontend i personalizuar që përcjell në adresën e vërtetë të pikës fundore, dhe një profil i rishkruar në një adresë të papërpunuar. AWS dokumenton kombinimin e regjistrimit të personalizuar plus përcjelljen si dështim me klientët e rinj të AWS. Kontrolli është i ngushtë; nuk është një vendim që çdo alias është i ndaluar.

Nuk është as rregull i përgjithshëm për protokollet VPN. Një remote numerik është plotësisht i vlefshëm në një vendosje të zakonshme OpenVPN, dhe shumë funksionojnë ashtu. Kufizimi vjen nga rregullimi i menaxhuar, jo nga protokolli poshtë tij.

Që e bën lehtësimin e verifikimit të certifikatës refleksin e gabuar. Nëse një profil dështon pas një ndryshimi adrese, çaktivizimi i verifikimit të serverit e zhvendos gabimin në vend që të rregullojë zgjidhjen ose kërkesën e përputhjes së adresës, dhe lë një klient që do të besojë gjithçka. Mbani CA-në e eksportuar, verifikimin e serverit dhe cilësimet e autentikimit të ndërsjellë saktësisht siç erdhën.

Listat e lejimit, dalja dhe DNS privat janë tri probleme të ndara

Një rregull firewalls që duhet të lejojë një destinacion përpara se laptopi të lidhet ka të bëjë me dëgjuesin e jashtëm. Jepini pronarit të rrjetit emrin e pikës fundore, transportin dhe portën e konfiguruar, pastaj pyesni nëse kontrolli i tyre mund të ndjekë sjelljen DNS të shërbimit. Një rregull që mban një adresë të kapur është një fotografi me një skadim të pashkruar. Nëse kontrolli pranon vetëm destinacione të pandryshueshme, zgjidhni atë boshllëk përpara hedhjes në treg në vend që të kodoni në heshtje një përgjigje.

Një partner që ka nevojë për një adresë burimi fikse për kërkesat e bëra pasi tuneli të jetë ngritur ka një kërkesë tjetër: daljen. Ajo që vëren një sajt varet nga rruga e aplikacionit dhe politika e tunelit të ndarë, jo nga adresa me të cilën u lidh klienti. Trafiku në tunel të ndarë mund të mos prekë fare AWS.

DNS privat brenda tunelit është shtresa e tretë. Zgjidhësi që u jepet klientëve përgjigjet për emra të brendshëm pas lidhjes; ai nuk mund të zgjidhë pikën fundore publike përpara se tuneli të ekzistojë. Dështimi i zgjidhjes së pikës fundore dhe dështimi i zgjidhjes së një aplikacioni të brendshëm ndodhin në faza të ndryshme, dhe përzierja e tyre ju çon te logu i gabuar.

Familja e adresave i përket të njëjtit listë. Një përgjigje IPv4 nuk thotë asgjë për rrugën e lejuar të një pike fundore IPv6 ose me dy stack, prandaj një fotografi e marrë në një familje nuk është provë për tjetrën.

Kontrolloni një lidhje pa fiksuar asgjë

Filloni nga profili ashtu siç u eksportua dhe lexoni çfarë kërkon në të vërtetë:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Pastaj krahasoni tre gjëra: emrin e pikës fundore që mban profili, adresën që klienti raporton për një provë të re, dhe atë ku zgjidhet emri tani. Një emër që zgjidhet vërteton vetëm se regjistrimi përgjigjet; transporti dhe autentikimi janë të ndarë, dhe pika fundore nuk duhet të përgjigjet ndaj ping. Logu i vetë klientit është burimi i vetëm për elementin e mesëm, prandaj kapeni gjatë provës dhe jo pas saj.

Një adresë që përgjigjet sot është provë për sot; emri është ajo që shërbimi mban të vlefshme. Shënoni vëzhgimin, dërgojeni te pronari i pikës fundore dhe lëreni profilin të tregojë emrin.

Dy zakone për t'i lënë: çaktivizimi i kontrolleve të certifikatës për të kaluar një handshake të ngecur, dhe grumbullimi i etiketave përpara emrit të pikës fundore me shpresën se njëra ngjitet. Etiketa zgjidhet përmes regjistrimit wildcard ose problemi është diku tjetër. Nëse një profil i konfiguruar saktë dështon gjithsesi, dërgoni pyetjen e saktë dhe ngjarjen e lidhjes, jo një emër hosti më të gjatë.

Përpara se ta mbyllni: profili ende mban emrin e eksportuar të pikës fundore, asnjë skedar hosts nuk e fikson adresën, remote në logun e klientit përputhet me një zgjidhje aktuale, dhe rregulli i firewalls emërton pikën fundore dhe jo një adresë. Ky është edhe statusi që i jepet personit tjetër.