DNS for AWS Client VPN-endpoint: hvorfor fastlåsning af den opløste IP fejler

I sidste uge gav dig +short dig én adresse til endpointnavnet i din AWS Client VPN-profil, og tunnelen blev oprettet. I denne uge står samme profil på 'Connecting' på din bærbare, mens en kollegas urørte kopi stadig virker. Intet blev blokeret, og certifikatet udløb ikke. Nogen erstattede endpointets værtsnavn med den opløste adresse, og tjenesten svarer ikke længere der. Det eksporterede navn er den del, der er bygget til at overleve den ændring.

Navnet i din profil er måske ikke det navn, der slås op

Profiler eksporteret fra Client VPN indeholder ofte remote-random-hostname. Med den indstilling slået til bygger klienten en engangsetiket, føjer den til endpointnavnet med et punktum og opløser det sammensatte navn. En wildcard-post i endpointets zone svarer på enhver etiket, og derfor opløses et opdigtet præfiks stadig, og derfor forbliver tricket usynligt, når du prøver at genskabe forespørgslen manuelt.

Så når du indsætter endpointnavnet i en terminal og får et svar, har du opløst et andet navn end det, klienten bruger ved forbindelse. Den uoverensstemmelse er ikke en fejl, der skal rettes i profilen. Etiketten genskabes med vilje: indstillingen forhindrer caches i at holde et forældet svar, og den identificerer aldrig din maskine eller session.

Jeg har ramt kompatibilitetstilfældet, hvor en klient ignorerer indstillingen helt. AWS dokumenterer omvejen: behold det rigtige endpointnavn, og sæt en tilfældig streng plus et punktum foran, og behandl det som et navngivningsmønster frem for en værdi, der skal indsættes. At anvende det på en gammel klient er rimeligt; at hardkode den præfikserede streng som endpoint er det ikke.

Hvorfor et gemt svar ikke kan forblive korrekt

Client VPN-endpointadresser administreres af AWS og ændrer sig over tid, hvilket dokumentationen for bedste praksis siger direkte. Et fanget svar er et øjebliksbillede af én opløsning. En profil, der hardkoder det, bliver en profil rettet mod en nedlagt vært, så snart tjenesten flytter, og fejlen ligner sjældent DNS: du får timeout på forbindelsen eller en fastlåst handshake, så folk jager routing og certifikater.

Det samme svar i /etc/hosts arver samme udløb med et ekstra problem. En hosts-post overlever genstart, gentagne eksporter og 'geninstaller klienten'-rettelser, så fejlen vender tilbage, hver gang adressen flytter. Jeg har set en ligge uskadelig i uger og derefter slå hver maskine, der bar den, ud, mens friske installationer forbandt normalt. Den opdeling, én gruppe fejler og en anden er fin på samme konto, er det billigste spor, du får.

Afgræns randomiseringen korrekt. Den sker pr. forbindelsesforsøg. En etableret tunnel opløser ikke sit endpoint igen, skifter ikke server midt i sessionen, og individuelle applikationsanmodninger vælger ikke hver en ny VPN-vært. Kun det næste forsøg opløser igen, og derfor siger en session, der virker hele eftermiddagen, intet om i morgen tidlig.

Hvad tjenesten kontrollerer, når tunnelen kommer op

Client VPN kræver, at den adresse, du er forbundet til, matcher en adresse, der er opløst for endpointets DNS-navn. Det ene krav forklarer flere fejl, der ser urelaterede ud: en brugerdefineret DNS-post, der peger et andet sted hen, en brugerdefineret frontend, der videresender til den rigtige endpointadresse, og en profil, der er skrevet om til en rå adresse. AWS dokumenterer ordningen med brugerdefineret post plus videresendelse som en fejl med nyere AWS-klienter. Kontrollen er snæver; den er ikke en dom om, at enhver alias er forbudt.

Det er heller ikke en generel regel om VPN-protokoller. Et numerisk remote er helt gyldigt i en almindelig OpenVPN-udrulning, og mange kører sådan. Begrænsningen kommer fra den administrerede ordning, ikke fra protokollen under den.

Hvilket gør lempelse af certifikatverifikation til den forkerte refleks. Hvis en profil fejler efter en adresseudskiftning, flytter deaktivering af serververifikation fejlen i stedet for at rette opløsningen eller kravet om adressematch, og efterlader en klient, der vil stole på hvad som helst. Behold den eksporterede CA, serververifikation og indstillinger for gensidig godkendelse præcis som de kom.

Tilladelseslister, udgående trafik og privat DNS er tre separate problemer

En firewallregel, der skal tillade en destination, før en bærbar opretter forbindelse, handler om den ydre listener. Giv netværksejeren endpointnavnet, transporten og den konfigurerede port, og spørg derefter, om deres kontrol kan følge tjenestens DNS-adfærd. En regel, der holder én fanget adresse, er et øjebliksbillede med en uskreven udløbsdato. Hvis kontrollen kun accepterer uforanderlige destinationer, skal du løse det hul før udrulning i stedet for stille at hardkode et svar.

En partner, der har brug for en fast kildeaddresse til anmodninger efter tunnelen er oppe, har et andet krav: udgående trafik. Hvad et websted ser, afhænger af applikationsruten og split-tunnel-politikken, ikke af den adresse, klienten forbandt til. Split-tunnelet trafik rører måske aldrig AWS.

Privat DNS inde i tunnelen er et tredje lag. Den resolver, der gives til klienter, svarer på interne navne efter forbindelse; den kan ikke opløse det offentlige endpoint, før tunnelen findes. Fejl i endpointopløsning og fejl i intern applikationsopløsning sker på forskellige stadier, og at blande dem sender dig til den forkerte log.

Adressefamilie hører til på samme liste. Et IPv4-svar siger intet om den tilladte vej for et IPv6- eller dual-stack-endpoint, så et øjebliksbillede taget i én familie er ikke bevis for den anden.

Kontroller en forbindelse uden at fastlåse noget

Start fra profilen som eksporteret, og læs, hvad den faktisk beder 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 derefter tre ting: endpointnavnet profilen indeholder, den adresse klienten rapporterer for et nyt forsøg, og hvad navnet opløses til lige nu. Et navn, der opløses, beviser kun, at posten svarer; transport og godkendelse er adskilt, og endpointet behøver ikke svare på ping. Klientens egen log er den eneste kilde til det midterste element, så fang den under forsøget i stedet for bagefter.

En adresse, der svarer i dag, er bevis om i dag; navnet er det, tjenesten holder gyldigt. Noter observationen, send den til den, der ejer endpointet, og lad profilen pege på navnet.

To vaner at droppe: at slå certifikatkontroller fra for at komme forbi en fastlåst handshake, og at stable etiketter foran endpointnavnet i håb om, at en hænger ved. En etiket opløses via wildcard-posten, eller også er problemet et andet sted. Hvis en korrekt konfigureret profil stadig fejler, send den præcise forespørgsel og forbindelseshændelsen, ikke et længere værtsnavn.

Før du lukker sagen: profilen bærer stadig det eksporterede endpointnavn, ingen hosts-fil fastlåser adressen, klientloggens remote matcher en aktuel opløsning, og firewallreglen navngiver endpointet frem for en adresse. Det er også den tilstand, du skal give videre til den næste.