DNS fan AWS Client VPN-einpunt: wêrom it fêstsetten fan it oploste IP mislearret
Ferfange de namme fan it AWS Client VPN-einpunt troch it adres dat jo oplost hawwe, en de tunnel wurket letter net mear. Hâld de eksportearre namme en syn willekeurige foarheaksel.
Ferline wike joech dig +short jo ien adres foar de einpuntnamme yn jo AWS Client VPN-profyl, en de tunnel ferbûn. Dizze wike stiet itselde profyl op 'Connecting' op jo laptop, wylst de ûnoantaaste kopy fan in kollega noch wurket. Neat waard blokkearre en it sertifikaat ferrûn net. Ien ferfong de hostnamme fan it einpunt troch dat oploste adres, en de tsjinst antwurdet dêr net mear. De eksportearre namme is it part dat boud is om dy feroaring te oerlibjen.
De namme yn jo profyl is miskien net de namme dy't opfrege wurdt
Profylen eksportearre út Client VPN drage faak remote-random-hostname. Mei dy opsje oan bout de klient in weismietlabel, foeget it mei in punt by de einpuntnamme en lost de kombinearre namme op. In wildcard-record yn 'e sône fan it einpunt antwurdet op elk label, dêrom lost in betocht foarheaksel noch op en dêrom bliuwt de trúk ûnsichtber as jo de fraach mei de hân besykje te reprodusearjen.
Dus as jo de einpuntnamme yn in terminal plakke en in antwurd krije, hawwe jo in oare namme oplost as dy't de klient by ferbining brûkt. Dat ferskil is gjin defekt om yn it profyl te ferbetterjen. It label wurdt mei opsetsin opnij makke: de opsje hâldt caches tsjin om in ferâldere antwurd te bewarjen, en it identifisearret nea jo masine of jo sesje.
Ik haw it kompatibiliteitsgefal sjoen wêrby't in klient de opsje folslein negearret. AWS dokumintearret de oplossing: hâld de echte einpuntnamme en set in willekeurige tekenrige plus in punt derfoar, en behannelje it as in namjouwingspatroan ynstee fan in wearde om te plakken. Dat op in âlde klient tapasse is ridlik; de foarheaksele tekenrige as einpunt fêstkodearje is dat net.
Wêrom in bewarre antwurd net korrekt bliuwe kin
Client VPN-einpuntadressen wurde troch AWS beheard en feroarje oer de tiid, wat de dokumintaasje oer bêste praktyken rjochtút seit. In fêstlein antwurd is in momintopname fan ien oplossing. In profyl dat it fêstkodearret wurdt in profyl rjochte op in bûten tsjinst steld host sadree't de tsjinst ferhuzet, en de flater liket komselden op DNS: jo krije in ferbindingstimeout of in fêstslachte handshake, dus minsken jeie op routing en sertifikaten.
Itselde antwurd yn /etc/hosts ervet deselde ferfaltermyn mei in ekstra probleem. In hosts-yngong oerlibbet werstarts, nije eksporten en 'ynstallearje de klient opnij'-reparaasjes, dus de flater komt werom elke kear as it adres ferhuzet. Ik haw sjoen dat ien wikenlang harmless lei en doe elke masine dy't it droech útskeakele, wylst nije ynstallaasjes normaal ferbûnen. Dy splitsing, ien groep mislearret en in oare is goed op itselde akkount, is de goedkeapste oanwizing dy't jo krije.
Behein de randomisaasje ek goed. It bart per ferbindingspoging. In fêstige tunnel lost syn einpunt net opnij op, wikselt net midden yn 'e sesje fan server, en yndividuele applikaasjefersiken kieze net elk in nije VPN-host. Allinnich de folgjende poging lost wer op, dêrom seit in sesje dy't de hiele middei wurket neat oer moarn moarn.
Wat de tsjinst kontrolearret as de tunnel omheech komt
Client VPN easket dat it adres wêr't jo mei ferbûn binne oerienkomt mei in adres dat foar de DNS-namme fan it einpunt oplost is. Dat iene eask ferklearret ferskate flaters dy't ûnferbânlik lykje: in oanpaste DNS-record dy't earne oars hinne wiist, in oanpaste frontend dy't trochstjoert nei it echte einpuntadres, en in profyl dat nei in rau adres weromskreaun is. AWS dokumintearret de kombinaasje fan oanpaste record en trochstjoere as in flater mei resinte AWS-kliïnten. De kontrôle is smel; it is gjin oardiel dat elk alias ferbean is.
It is ek gjin algemiene regel oer VPN-protokollen. In numerike remote is folslein jildich yn in gewoane OpenVPN-ynset, en in protte wurkje sa. De beheining komt fan 'e beheard arrangement, net fan it protokol dêrûnder.
Wat it fersêftsjen fan sertifikaatferifikaasje de ferkearde refleks makket. As in profyl nei in adreswiksel mislearret, ferpleatst it útskeakeljen fan serverferifikaasje de flater ynstee fan de oplossing of de adresoerienkomst te reparearjen, en lit in klient efter dy't alles fertrouwe sil. Hâld de eksportearre CA, serverferifikaasje en ynstellings foar wjerskanten autentikaasje krekt sa't se kamen.
Tolistings, útgong en privee DNS binne trije aparte problemen
In firewallregel dy't in bestimming tastean moat foar't in laptop ferbynt, giet oer de bûtenste listener. Jou de netwurkseigner de einpuntnamme, it transport en de konfigurearre poarte, freegje dan oft har kontrôle it DNS-gedrach fan 'e tsjinst folgje kin. In regel dy't ien fêstlein adres hâldt is in momintopname mei in ûnskreaune ferfaltermyn. As de kontrôle allinnich ûnferoarlike bestimmingen akseptearret, los dy gat op foar de útrol, ynstee fan stil in antwurd fêst te kodearjen.
In partner dy't in fêst boarneadres nedich hat foar fersiken nei't de tunnel omheech is, hat in oare eask: útgong. Wat in webside sjocht hinget ôf fan 'e applikaasjeroute en it belied fan split-tunnel, net fan it adres wêr't de klient mei ferbûn. Split-tunnelferkear rekket AWS miskien hielendal net.
Privee DNS binnen de tunnel is in tredde laach. De resolver dy't oan klanten jûn wurdt antwurdet nei ferbining op ynterne nammen; hy kin it iepenbiere einpunt net oplosse foar't de tunnel bestiet. Flater by einpuntoplossing en flater by ynterne applikaasjeoplossing barre yn ferskillende fazen, en it mingen derfan stjoert jo nei de ferkearde log.
Adresfamylje heart yn deselde list. In IPv4-antwurd seit neat oer it tastiene paad fan in IPv6- of dûbeld-stack-einpunt, dus in momintopname yn ien famylje is gjin bewiis foar de oare.
Kontrolearje in ferbining sûnder eat fêst te setten
Begjin by it profyl sa't it eksportearre is en lês wat it eins freget:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'Fergelykje dan trije dingen: de einpuntnamme dy't it profyl hat, it adres dat de klient foar in nije poging rapportearret, en wêr't de namme no nei oplost. In namme dy't oplost bewiist allinnich dat it record antwurdet; transport en autentikaasje binne apart, en it einpunt hoecht net op in ping te antwurdzjen. De eigen log fan 'e klient is de iennige boarne foar it middenstik, dus fêstlizze it by de poging en net dernei.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
In adres dat hjoed antwurdet is bewiis oer hjoed; de namme is wat de tsjinst jildich hâldt. Skriuw de waarnimming op, stjoer it nei wa't it einpunt hat, en lit it profyl nei de namme wize.
Twa gewoanten om te litten: sertifikaatkontrôles útskeakelje om in fêstslachte handshake foarby te kommen, en labels foar de einpuntnamme opinoar stapelje yn 'e hope dat ien hingje bliuwt. In label lost op fia it wildcard-record of it probleem is earne oars. As in korrekt konfigurearre profyl noch mislearret, stjoer de krekte fraach en it ferbiningsevenemint, gjin langer hostnamme.
Foar't jo it slute: it profyl draacht noch de eksportearre einpuntnamme, gjin hosts-bestân set it adres fêst, de remote yn 'e klientlog komt oerien mei in aktuele oplossing en de firewallregel neamt it einpunt ynstee fan in adres. Dat is ek de steat om oan 'e folgjende persoan te jaan.