DNS for AWS Client VPN-endepunktet: kvifor festing av den oppløyste IP-adressa feilar

Førre veke gav dig +short deg éi adresse for endepunktnamnet i AWS Client VPN-profilen din, og tunnelen kopla til. Denne veka står same profil på 'Connecting' på laptoppen din medan ein kollega sin urørte kopi framleis verkar. Ingenting vart blokkert, og sertifikatet gjekk ikkje ut. Nokon bytte ut vertsnamnet til endepunktet med den oppløyste adressa, og tenesta svarar ikkje lenger der. Det eksporterte namnet er delen som er bygd for å overleve den endringa.

Namnet i profilen din er kanskje ikkje namnet som blir slått opp

Profilar eksporterte frå Client VPN inneheld ofte remote-random-hostname. Med det valet på byggjer klienten ei eingongsetikett, føyer ho til endepunktnamnet med eit punktum og løyser opp det samansette namnet. Ein wildcard-post i sona til endepunktet svarar på kva etikett som helst, og difor blir eit oppdikta prefiks framleis løyst opp, og difor blir trikset usynleg når du prøver å gjenskape spørjinga manuelt.

Så når du limer inn endepunktnamnet i ein terminal og får svar, har du løyst opp eit anna namn enn det klienten brukar ved tilkopling. Det avviket er ikkje ein feil som skal rettast i profilen. Etiketten blir generert på nytt med vilje: valet hindrar hurtiglagre i å halde eit utdatert svar, og det identifiserer aldri maskina eller økta di.

Eg har møtt kompatibilitetstilfellet der ein klient ignorerer valet heilt. AWS dokumenterer omvegen: hald på det ekte endepunktnamnet og set ein tilfeldig streng pluss eit punktum framfor, og handsam det som eit navnemønster og ikkje som ein verdi som skal limast inn. Å bruke det på ein gammal klient er rimeleg; å hardkode den prefiksa strengen som endepunkt er det ikkje.

Kvifor eit lagra svar ikkje kan halde fram med å vere rett

Client VPN-endepunktadresser blir styrte av AWS og endrar seg over tid, noko dokumentasjonen for beste praksis seier rett ut. Eit fanga svar er eit augeblinksbilete av éi oppløysing. Ein profil som hardkodar det, blir ein profil retta mot ein nedlagd vert så snart tenesta flyttar seg, og feilen ser sjeldan ut som DNS: du får tidsavbrot på tilkoplinga eller ein fastlåst handshake, så folk jagar ruting og sertifikat.

Det same svaret i /etc/hosts arvar same utløp med eit ekstra problem. Ein hosts-oppføring overlever omstart, nye eksportar og 'reinstaller klienten'-rettingar, så feilen kjem tilbake kvar gong adressa flyttar seg. Eg har sett ein liggje ufarleg i veker og deretter slå ut kvar maskin som bar han, medan ferske installasjonar kopla til normalt. Den splittinga, éin gruppe feilar og ein annan er fin på same konto, er det billegaste sporet du får.

Avgrens randomiseringa rett. Ho skjer per tilkoplingsforsøk. Ein etablert tunnel løyser ikkje opp endepunktet sitt på nytt, byter ikkje server midt i økta, og individuelle applikasjonsførespurnader vel ikkje kvar sin nye VPN-vert. Berre neste forsøk løyser opp igjen, og difor seier ei økt som verkar heile ettermiddagen ingenting om i morgon tidleg.

Kva tenesta kontrollerer når tunnelen kjem opp

Client VPN krev at adressa du er kopla til, samsvarar med ei adresse som er løyst opp for DNS-namnet til endepunktet. Det eine kravet forklarer fleire feil som ser urelaterte ut: ein eigendefinert DNS-post som peikar ein annan stad, ein eigendefinert frontend som videresender til den ekte endepunktadressa, og ein profil som er skriven om til ei rå adresse. AWS dokumenterer ordninga med eigendefinert post pluss videresending som ein feil med nyare AWS-klientar. Kontrollen er smal; han er ikkje ein dom om at kvar alias er forbode.

Det er heller ikkje ein generell regel om VPN-protokollar. Eit numerisk remote er heilt gyldig i ei vanleg OpenVPN-utrulling, og mange køyrer slik. Avgrensinga kjem frå den styrte ordninga, ikkje frå protokollen under henne.

Noko som gjer lempling av sertifikatverifisering til den gale refleksen. Viss ein profil feilar etter ei adresseutskifting, flyttar deaktivering av serververifisering feilen i staden for å reparere oppløysinga eller kravet om adressesamsvar, og etterlèt ein klient som vil stole på kva som helst. Hald på den eksporterte CA-en, serververifiseringa og innstillingane for gjensidig autentisering nøyaktig slik dei kom.

Tillatingslister, utgåande trafikk og privat DNS er tre separate problem

Ein brannmurregel som må tillate ein destinasjon før ein laptop koplar til, handlar om den ytre lyttaren. Gi netteigaren endepunktnamnet, transporten og den konfigurerte porten, og spør deretter om kontrollen deira kan følgje DNS-åtferda til tenesta. Ein regel som held éi fanga adresse, er eit augeblinksbilete med ein uskriven utløpsdato. Viss kontrollen berre godtek uforanderlege destinasjonar, løys det gapet før utrulling i staden for å hardkode eit svar i det stille.

Ein partnar som treng ei fast kjeldeadresse for førespurnader etter at tunnelen er oppe, har eit anna krav: utgåande trafikk. Det ein nettstad ser, avheng av applikasjonsruta og split-tunnel-policyen, ikkje av adressa klienten kopla til. Split-tunna trafikk rører kanskje aldri AWS i det heile.

Privat DNS inne i tunnelen er eit tredje lag. Resolveren som blir gitt til klientane, svarar på interne namn etter tilkopling; han kan ikkje løyse opp det offentlege endepunktet før tunnelen finst. Feil i endepunktoppløysing og feil i intern applikasjonsoppløysing skjer på ulike steg, og å blande dei sender deg til feil logg.

Adressefamilie høyrer heime på same liste. Eit IPv4-svar seier ingenting om den tillatne vegen for eit IPv6- eller dual-stack-endepunkt, så eit augeblinksbilete teke i éin familie er ikkje bevis for den andre.

Kontroller ei tilkopling utan å feste noko

Start frå profilen slik han vart eksportert, og les kva han faktisk ber om:

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

Samanlikn deretter tre ting: endepunktnamnet profilen held, adressa klienten rapporterer for eit nytt forsøk, og kva namnet blir løyst opp til akkurat no. Eit namn som blir løyst opp, beviser berre at posten svarar; transport og autentisering er separate, og endepunktet treng ikkje svare på ping. Klienten sin eigen logg er den einaste kjelda for det midtre elementet, så fang han under forsøket og ikkje etterpå.

Ei adresse som svarar i dag, er bevis om i dag; namnet er det tenesta held gyldig. Noter observasjonen, send han til den som eig endepunktet, og lat profilen peike på namnet.

To vanar å slutte med: å slå av sertifikatsjekkar for å kome forbi ein fastlåst handshake, og å stable etikettar framfor endepunktnamnet i håp om at éin heng igjen. Ein etikett blir løyst opp via wildcard-posten, eller så er problemet ein annan stad. Viss ein rett konfigurert profil framleis feilar, send den nøyaktige spørjinga og tilkoplingshendinga, ikkje eit lengre vertsnamn.

Før du lukkar saka: profilen ber framleis det eksporterte endepunktnamnet, inga hosts-fil festar adressa, klientloggens remote samsvarar med ei gjeldande oppløysing, og brannmurregelen namngir endepunktet i staden for ei adresse. Det er òg tilstanden du skal gi vidare til neste person.