DNS for AWS Client VPN-endepunktet: hvorfor festing av den oppløste IP-en feiler

Forrige uke ga dig +short deg én adresse for endepunktnavnet i AWS Client VPN-profilen din, og tunnelen koblet til. Denne uken står samme profil på 'Connecting' på laptopen din mens en kollegas urørte kopi fortsatt virker. Ingenting ble blokkert, og sertifikatet utløp ikke. Noen erstattet vertsnavnet til endepunktet med den oppløste adressen, og tjenesten svarer ikke lenger der. Det eksporterte navnet er delen som er bygget for å overleve den endringen.

Navnet i profilen din er kanskje ikke navnet som slås opp

Profiler eksportert fra Client VPN inneholder ofte remote-random-hostname. Med det valget på bygger klienten en engangsetikett, føyer den til endepunktnavnet med et punktum og løser opp det sammensatte navnet. En wildcard-post i sonen til endepunktet svarer på enhver etikett, og derfor løses et oppdiktet prefiks fortsatt opp, og derfor forblir trikset usynlig når du prøver å gjenskape spørringen manuelt.

Så når du limer inn endepunktnavnet i en terminal og får svar, har du løst opp et annet navn enn det klienten bruker ved tilkobling. Det avviket er ikke en feil som skal rettes i profilen. Etiketten genereres på nytt med vilje: valget hindrer hurtiglagre i å holde et utdatert svar, og det identifiserer aldri maskinen eller økten din.

Jeg har truffet kompatibilitetstilfellet der en klient ignorerer valget helt. AWS dokumenterer omveien: behold det ekte endepunktnavnet og sett en tilfeldig streng pluss et punktum foran, og behandle det som et navnemønster og ikke som en verdi som skal limes inn. Å bruke det på en gammel klient er rimelig; å hardkode den prefiksede strengen som endepunkt er det ikke.

Hvorfor et lagret svar ikke kan forbli riktig

Client VPN-endepunktadresser administreres av AWS og endres over tid, noe dokumentasjonen for beste praksis sier rett ut. Et fanget svar er et øyeblikksbilde av én oppløsning. En profil som hardkoder det, blir en profil rettet mot en nedlagt vert så snart tjenesten flytter seg, og feilen ser sjelden ut som DNS: du får tidsavbrudd på tilkoblingen eller en fastlåst handshake, så folk jager ruting og sertifikater.

Det samme svaret i /etc/hosts arver samme utløp med et ekstra problem. En hosts-oppføring overlever omstarter, nye eksporter og 'reinstaller klienten'-rettelser, så feilen kommer tilbake hver gang adressen flytter seg. Jeg har sett en ligge ufarlig i uker og deretter slå ut hver maskin som bar den, mens ferske installasjoner koblet til normalt. Den splittelsen, én gruppe feiler og en annen er fin på samme konto, er det billigste sporet du får.

Avgrens randomiseringen riktig. Den skjer per tilkoblingsforsøk. En etablert tunnel løser ikke opp endepunktet sitt på nytt, bytter ikke server midt i økten, og individuelle applikasjonsforespørsler velger ikke hver sin nye VPN-vert. Bare neste forsøk løser opp igjen, og derfor sier en økt som virker hele ettermiddagen ingenting om i morgen tidlig.

Hva tjenesten kontrollerer når tunnelen kommer opp

Client VPN krever at adressen du er koblet til, samsvarer med en adresse som er løst opp for DNS-navnet til endepunktet. Det ene kravet forklarer flere feil som ser urelaterte ut: en egendefinert DNS-post som peker et annet sted, en egendefinert frontend som videresender til den ekte endepunktadressen, og en profil som er skrevet om til en rå adresse. AWS dokumenterer ordningen med egendefinert post pluss videresending som en feil med nyere AWS-klienter. Kontrollen er smal; den er ikke en dom om at enhver alias er forbudt.

Det er heller ikke en generell regel om VPN-protokoller. En numerisk remote er helt gyldig i en vanlig OpenVPN-utrulling, og mange kjører slik. Begrensningen kommer fra den administrerte ordningen, ikke fra protokollen under den.

Hvilket gjør lemping av sertifikatverifisering til den gale refleksen. Hvis en profil feiler etter en adresseutskiftning, flytter deaktivering av serververifisering feilen i stedet for å reparere oppløsningen eller kravet om adressesamsvar, og etterlater en klient som vil stole på hva som helst. Behold den eksporterte CA-en, serververifiseringen og innstillingene for gjensidig autentisering nøyaktig slik de kom.

Tillatelseslister, utgående trafikk og privat DNS er tre separate problemer

En brannmurregel som må tillate en destinasjon før en laptop kobler til, handler om den ytre lytteren. Gi nettverkseieren endepunktnavnet, transporten og den konfigurerte porten, og spør deretter om kontrollen deres kan følge tjenestens DNS-atferd. En regel som holder én fanget adresse, er et øyeblikksbilde med en uskrevet utløpsdato. Hvis kontrollen bare godtar uforanderlige destinasjoner, løs det gapet før utrulling i stedet for å hardkode et svar i stillhet.

En partner som trenger en fast kildeadresse for forespørsler etter at tunnelen er oppe, har et annet krav: utgående trafikk. Det et nettsted ser, avhenger av applikasjonsruten og split-tunnel-policyen, ikke av adressen klienten koblet til. Split-tunnelet trafikk berører kanskje aldri AWS i det hele tatt.

Privat DNS inne i tunnelen er et tredje lag. Resolveren som gis til klientene, svarer på interne navn etter tilkobling; den kan ikke løse opp det offentlige endepunktet før tunnelen finnes. Feil i endepunktoppløsning og feil i intern applikasjonsoppløsning skjer på ulike stadier, og å blande dem sender deg til feil logg.

Adressefamilie hører hjemme på samme liste. Et IPv4-svar sier ingenting om den tillatte veien for et IPv6- eller dual-stack-endepunkt, så et øyeblikksbilde tatt i én familie er ikke bevis for den andre.

Kontroller en tilkobling uten å feste noe

Start fra profilen slik den ble eksportert, og les hva den 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)'

Sammenlign deretter tre ting: endepunktnavnet profilen holder, adressen klienten rapporterer for et nytt forsøk, og hva navnet løses opp til akkurat nå. Et navn som løses opp, beviser bare at posten svarer; transport og autentisering er separate, og endepunktet trenger ikke svare på ping. Klientens egen logg er den eneste kilden for det midterste elementet, så fang den under forsøket og ikke etterpå.

En adresse som svarer i dag, er bevis om i dag; navnet er det tjenesten holder gyldig. Noter observasjonen, send den til den som eier endepunktet, og la profilen peke på navnet.

To vaner å slutte med: å slå av sertifikatsjekker for å komme forbi en fastlåst handshake, og å stable etiketter foran endepunktnavnet i håp om at én henger igjen. En etikett løses opp via wildcard-posten, eller så er problemet et annet sted. Hvis en riktig konfigurert profil fortsatt feiler, send den nøyaktige spørringen og tilkoblingshendelsen, ikke et lengre vertsnavn.

Før du lukker saken: profilen bærer fortsatt det eksporterte endepunktnavnet, ingen hosts-fil fester adressen, klientloggens remote samsvarer med en gjeldende oppløsning, og brannmurregelen navngir endepunktet i stedet for en adresse. Det er også tilstanden du skal gi videre til neste person.