DNS van het AWS Client VPN-endpoint: waarom het vastzetten van het opgeloste IP mislukt

Vorige week gaf dig +short u één adres voor de endpointnaam in uw AWS Client VPN-profiel, en de tunnel verbond. Deze week blijft hetzelfde profiel op 'Connecting' staan op uw laptop, terwijl de onaangeroerde kopie van een collega nog werkt. Niets werd geblokkeerd en het certificaat verliep niet. Iemand verving de hostnaam van het endpoint door dat opgeloste adres, en de dienst antwoordt daar niet meer. De geëxporteerde naam is het deel dat is gebouwd om die verandering te overleven.

De naam in uw profiel is misschien niet de naam die wordt opgevraagd

Profielen die uit Client VPN worden geëxporteerd, bevatten vaak remote-random-hostname. Met die optie aan bouwt de client een wegwerplabel, voegt dat met een punt toe aan de endpointnaam en lost de gecombineerde naam op. Een wildcardrecord in de zone van het endpoint antwoordt op elk label, waardoor een verzonnen prefix nog steeds oplost en waardoor de truc onzichtbaar blijft wanneer u de query met de hand probeert te reproduceren.

Dus wanneer u de endpointnaam in een terminal plakt en een antwoord krijgt, hebt u een andere naam opgelost dan die de client bij het verbinden gebruikt. Dat verschil is geen defect dat in het profiel moet worden gecorrigeerd. Het label wordt met opzet opnieuw gegenereerd: de optie voorkomt dat caches een verouderd antwoord vasthouden, en ze identificeert nooit uw machine of uw sessie.

Ik ben het compatibiliteitsgeval tegengekomen waarin een client de optie volledig negeert. AWS documenteert de omweg: houd de echte endpointnaam en zet er een willekeurige string plus een punt voor, en behandel dat als een naamgevingspatroon en niet als een waarde om te plakken. Dat op een oude client toepassen is redelijk; de geprefixte string als endpoint hardcoderen is dat niet.

Waarom een bewaard antwoord niet juist kan blijven

Endpointadressen van Client VPN worden door AWS beheerd en veranderen in de loop van de tijd, wat de documentatie over best practices ronduit zegt. Een vastgelegd antwoord is een momentopname van één resolutie. Een profiel dat dit hardcodeert, wordt een profiel dat op een buiten gebruik gestelde host is gericht zodra de dienst verhuist, en de fout ziet er zelden uit als DNS: u krijgt een verbindingstime-out of een vastgelopen handshake, dus mensen jagen op routing en certificaten.

Hetzelfde antwoord in /etc/hosts erft dezelfde vervaldatum met een extra probleem. Een hosts-item overleeft herstarts, nieuwe exports en 'herinstalleer de client'-reparaties, dus de fout komt terug telkens wanneer het adres verhuist. Ik heb gezien dat er één wekenlang onschadelijk stond en daarna elke machine die het droeg uitschakelde, terwijl nieuwe installaties normaal verbonden. Die splitsing, één groep faalt en een andere is in orde op hetzelfde account, is de goedkoopste aanwijzing die u krijgt.

Begrens de randomisatie correct. Die gebeurt per verbindingspoging. Een bestaande tunnel lost zijn endpoint niet opnieuw op, wisselt niet midden in de sessie van server, en afzonderlijke applicatieverzoeken kiezen niet elk een nieuwe VPN-host. Alleen de volgende poging lost opnieuw op, daarom zegt een sessie die de hele middag werkt niets over morgenochtend.

Wat de dienst controleert wanneer de tunnel omhoog komt

Client VPN vereist dat het adres waarop u bent verbonden overeenkomt met een adres dat voor de DNS-naam van het endpoint is opgelost. Die ene eis verklaart verschillende fouten die onsamenhangend lijken: een aangepast DNS-record dat elders naartoe wijst, een aangepaste frontend die doorstuurt naar het echte endpointadres, en een profiel dat is herschreven naar een onbewerkt adres. AWS documenteert de combinatie van aangepast record en doorsturen als een fout bij recente AWS-clients. De controle is smal; het is geen uitspraak dat elke alias verboden is.

Het is ook geen algemene regel over VPN-protocollen. Een numerieke remote is volledig geldig in een gewone OpenVPN-implementatie, en veel daarvan werken zo. De beperking komt van de beheerde opzet, niet van het protocol eronder.

Wat het versoepelen van certificaatverificatie de verkeerde reflex maakt. Als een profiel na een adreswissel faalt, verplaatst het uitschakelen van serververificatie de fout in plaats van de resolutie of de adresmatch-eis te repareren, en laat een client achter die alles zal vertrouwen. Houd de geëxporteerde CA, serververificatie en instellingen voor wederzijdse authenticatie precies zoals ze kwamen.

Toelatingslijsten, egress en privé-DNS zijn drie afzonderlijke problemen

Een firewallregel die een bestemming moet toestaan voordat een laptop verbindt, gaat over de buitenste listener. Geef de netwerkeigenaar de endpointnaam, het transport en de geconfigureerde poort, en vraag dan of hun controle het DNS-gedrag van de dienst kan volgen. Een regel die één vastgelegd adres bevat, is een momentopname met een ongeschreven vervaldatum. Als de controle alleen onveranderlijke bestemmingen accepteert, los die kloof op vóór de uitrol in plaats van stil een antwoord te hardcoderen.

Een partner die een vast bronadres nodig heeft voor verzoeken nadat de tunnel omhoog is, heeft een andere eis: egress. Wat een website ziet, hangt af van de applicatieroute en het split-tunnelbeleid, niet van het adres waarmee de client verbond. Split-tunnelverkeer raakt AWS misschien helemaal niet.

Privé-DNS in de tunnel is een derde laag. De resolver die clients krijgen, antwoordt na de verbinding op interne namen; hij kan het openbare endpoint niet oplossen voordat de tunnel bestaat. Een fout in endpointresolutie en een fout in interne applicatieresolutie gebeuren in verschillende fasen, en ze door elkaar halen stuurt u naar het verkeerde log.

Adresfamilie hoort in dezelfde lijst. Een IPv4-antwoord zegt niets over het toegestane pad van een IPv6- of dual-stack-endpoint, dus een momentopname in één familie is geen bewijs voor de andere.

Controleer een verbinding zonder iets vast te zetten

Begin bij het profiel zoals het is geëxporteerd en lees wat het werkelijk vraagt:

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

Vergelijk dan drie dingen: de endpointnaam die het profiel bevat, het adres dat de client voor een nieuwe poging meldt, en waar de naam nu naar oplost. Een naam die oplost bewijst alleen dat het record antwoordt; transport en authenticatie staan apart, en het endpoint hoeft niet op een ping te antwoorden. Het eigen log van de client is de enige bron voor het middelste item, dus leg het vast tijdens de poging en niet erna.

Een adres dat vandaag antwoordt is bewijs over vandaag; de naam is wat de dienst geldig houdt. Noteer de waarneming, stuur die naar de eigenaar van het endpoint, en laat het profiel naar de naam wijzen.

Twee gewoonten om te laten varen: certificaatcontroles uitschakelen om een vastgelopen handshake te passeren, en labels voor de endpointnaam stapelen in de hoop dat er één blijft hangen. Een label lost op via het wildcardrecord, of het probleem zit elders. Als een correct geconfigureerd profiel toch faalt, stuur de exacte query en de verbindingsgebeurtenis, geen langere hostnaam.

Voordat u het afsluit: het profiel draagt nog de geëxporteerde endpointnaam, geen hosts-bestand zet het adres vast, de remote in het clientlog komt overeen met een actuele resolutie, en de firewallregel noemt het endpoint in plaats van een adres. Dat is ook de toestand die u aan de volgende persoon geeft.