DNS för AWS Client VPN-slutpunkten: varför fästning av den upplösta IP-adressen misslyckas

Förra veckan gav dig +short dig en adress för slutpunktsnamnet i din AWS Client VPN-profil, och tunneln anslöt. Den här veckan står samma profil på 'Connecting' på din laptop medan en kollegas orörda kopia fortfarande fungerar. Ingenting blockerades och certifikatet gick inte ut. Någon ersatte slutpunktens värdnamn med den upplösta adressen, och tjänsten svarar inte längre där. Det exporterade namnet är den del som är byggd för att överleva den förändringen.

Namnet i din profil är kanske inte namnet som slås upp

Profiler som exporteras från Client VPN innehåller ofta remote-random-hostname. Med det alternativet på bygger klienten en engångsetikett, fogar den till slutpunktsnamnet med en punkt och löser upp det kombinerade namnet. En wildcard-post i slutpunktens zon svarar på vilken etikett som helst, vilket är varför ett påhittat prefix fortfarande löses upp och varför tricket förblir osynligt när du försöker återskapa frågan för hand.

Så när du klistrar in slutpunktsnamnet i en terminal och får ett svar har du löst upp ett annat namn än det klienten använder vid anslutning. Den avvikelsen är inte en defekt att rätta i profilen. Etiketten återskapas med avsikt: alternativet hindrar cachar från att hålla ett inaktuellt svar, och det identifierar aldrig din maskin eller session.

Jag har stött på kompatibilitetsfallet där en klient helt ignorerar alternativet. AWS dokumenterar kringgåendet: behåll det riktiga slutpunktsnamnet och sätt en slumpmässig sträng plus en punkt framför, och behandla det som ett namnmönster och inte som ett värde att klistra in. Att tillämpa det på en gammal klient är rimligt; att hårdkoda den prefixade strängen som slutpunkt är det inte.

Varför ett sparat svar inte kan förbli korrekt

Client VPN-slutpunkters adresser hanteras av AWS och ändras över tid, vilket dokumentationen för bästa praxis säger rakt ut. Ett fångat svar är en ögonblicksbild av en upplösning. En profil som hårdkodar det blir en profil riktad mot en avvecklad värd så snart tjänsten flyttar, och felet ser sällan ut som DNS: du får en anslutningstimeout eller en fastnad handshake, så folk jagar routing och certifikat.

Samma svar i /etc/hosts ärver samma utgång med ett extra problem. En hosts-post överlever omstarter, nya exporter och 'installera om klienten'-reparationer, så felet återkommer varje gång adressen flyttar. Jag har sett en ligga ofarlig i veckor och sedan slå ut varje maskin som bar den, medan färska installationer anslöt normalt. Den uppdelningen, en grupp misslyckas och en annan är okej på samma konto, är den billigaste ledtråden du får.

Avgränsa slumpningen rätt. Den sker per anslutningsförsök. En etablerad tunnel löser inte upp sin slutpunkt igen, byter inte server mitt i sessionen, och enskilda applikationsförfrågningar väljer inte var sin nya VPN-värd. Bara nästa försök löser upp igen, vilket är varför en session som fungerar hela eftermiddagen inte säger något om i morgon bitti.

Vad tjänsten kontrollerar när tunneln kommer upp

Client VPN kräver att adressen du är ansluten till matchar en adress som lösts upp för slutpunktens DNS-namn. Det enda kravet förklarar flera fel som verkar orelaterade: en anpassad DNS-post som pekar någon annanstans, en anpassad frontend som vidarebefordrar till den riktiga slutpunktsadressen, och en profil som skrivits om till en rå adress. AWS dokumenterar arrangemanget med anpassad post plus vidarebefordran som ett fel med nyare AWS-klienter. Kontrollen är snäv; den är inte en dom att varje alias är förbjudet.

Det är inte heller en allmän regel om VPN-protokoll. En numerisk remote är helt giltig i en vanlig OpenVPN-distribution, och många kör så. Begränsningen kommer från det hanterade arrangemanget, inte från protokollet under det.

Vilket gör att lätta på certifikatverifieringen till fel reflex. Om en profil misslyckas efter ett adressbyte flyttar avstängningen av serververifiering felet i stället för att reparera upplösningen eller kravet på adressmatchning, och lämnar en klient som kommer att lita på vad som helst. Behåll den exporterade CA:n, serververifieringen och inställningarna för ömsesidig autentisering exakt som de kom.

Tillåtelselistor, utgående trafik och privat DNS är tre separata problem

En brandväggsregel som måste tillåta en destination innan en laptop ansluter handlar om den yttre lyssnaren. Ge nätverksägaren slutpunktsnamnet, transporten och den konfigurerade porten, och fråga sedan om deras kontroll kan följa tjänstens DNS-beteende. En regel som håller en fångad adress är en ögonblicksbild med ett oskrivet utgångsdatum. Om kontrollen bara accepterar oföränderliga destinationer, lös den luckan före utrullning i stället för att tyst hårdkoda ett svar.

En partner som behöver en fast källadress för förfrågningar efter att tunneln är uppe har ett annat krav: utgående trafik. Vad en webbplats ser beror på applikationsrutten och split-tunnel-policyn, inte på adressen klienten anslöt till. Split-tunnel-trafik kanske aldrig rör AWS alls.

Privat DNS inne i tunneln är ett tredje lager. Resolvern som ges till klienterna svarar på interna namn efter anslutning; den kan inte lösa upp den publika slutpunkten innan tunneln finns. Fel i slutpunktsupplösning och fel i intern applikationsupplösning sker i olika faser, och att blanda dem skickar dig till fel logg.

Adressfamiljen hör hemma i samma lista. Ett IPv4-svar säger ingenting om den tillåtna vägen för en IPv6- eller dual-stack-slutpunkt, så en ögonblicksbild tagen i en familj är inte bevis för den andra.

Kontrollera en anslutning utan att fästa något

Börja från profilen som den exporterades och läs vad den faktiskt begär:

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

Jämför sedan tre saker: slutpunktsnamnet profilen håller, adressen klienten rapporterar för ett nytt försök, och vad namnet löses upp till just nu. Ett namn som löses upp bevisar bara att posten svarar; transport och autentisering är separata, och slutpunkten behöver inte svara på ping. Klientens egen logg är den enda källan för det mittersta, så fånga den under försöket och inte efteråt.

En adress som svarar i dag är bevis om i dag; namnet är det tjänsten håller giltigt. Anteckna observationen, skicka den till den som äger slutpunkten och låt profilen peka på namnet.

Två vanor att släppa: att stänga av certifikatkontroller för att komma förbi en fastnad handshake, och att stapla etiketter framför slutpunktsnamnet i hopp om att en fastnar. En etikett löses upp via wildcard-posten, eller så är problemet någon annanstans. Om en korrekt konfigurerad profil fortfarande misslyckas, skicka den exakta frågan och anslutningshändelsen, inte ett längre värdnamn.

Innan du stänger det: profilen bär fortfarande det exporterade slutpunktsnamnet, ingen hosts-fil fäster adressen, klientloggens remote matchar en aktuell upplösning, och brandväggsregeln namnger slutpunkten i stället för en adress. Det är också tillståndet du lämnar över till nästa person.