DNS koncového bodu AWS Client VPN: proč zafixování přeložené IP nefunguje

Minulý týden vám dig +short dalo jednu adresu pro název koncového bodu ve vašem profilu AWS Client VPN a tunel se připojil. Tento týden stejný profil na vašem notebooku zůstává na 'Connecting', zatímco nedotčená kopie kolegy stále funguje. Nic nebylo blokováno a certifikát nevypršel. Někdo nahradil název hostitele koncového bodu tou přeloženou adresou a služba tam už neodpovídá. Exportovaný název je část navržená tak, aby tuto změnu přežila.

Název ve vašem profilu nemusí být název, na který se dotazujete

Profily exportované z Client VPN často obsahují remote-random-hostname. Když je tato volba zapnutá, klient vytvoří jednorázový štítek, spojí ho s názvem koncového bodu tečkou a přeloží složený název. Divoký záznam v zóně koncového bodu odpovídá na jakýkoli štítek, proto vymyšlený prefix stále funguje a proto ten trik zůstává neviditelný, když se dotaz pokusíte zopakovat ručně.

Když tedy vložíte název koncového bodu do terminálu a dostanete odpověď, přeložili jste jiný název, než který klient používá při připojení. Tento nesoulad není vada, kterou byste měli v profilu opravovat. Štítek se znovu generuje záměrně: volba brání tomu, aby keše držely zastaralou odpověď, a nikdy neidentifikuje váš stroj ani relaci.

Narazil jsem na případ kompatibility, kdy klient volbu úplně ignoruje. AWS dokumentuje obejití: ponechte skutečný název koncového bodu a před něj přidejte náhodný řetězec a tečku, berte to jako vzor pojmenování, ne jako hodnotu k vložení. Použít to u starého klienta je rozumné; natvrdo zakódovat řetězec s prefixem jako koncový bod není.

Proč uložená odpověď nemůže zůstat správná

Adresy koncového bodu Client VPN spravuje AWS a mění se v čase, což dokumentace osvědčených postupů říká přímo. Zachycená odpověď je snímek jednoho překladu. Profil, který ji natvrdo zakóduje, se stane profilem namířeným na vyřazený hostitel, jakmile se služba přesune, a selhání málokdy vypadá jako DNS: dostanete časový limit připojení nebo zaseknutý handshake, takže lidé honí směrování a certifikáty.

Stejná odpověď v /etc/hosts dědí stejnou expiraci s dalším problémem. Záznam hosts přežije restarty, nové exporty i opravy 'přeinstalujte klienta', takže selhání se vrací pokaždé, když se adresa přesune. Viděl jsem jeden, jak týdny ležel neškodně, a pak vyřadil každý stroj, který ho nesl, zatímco čerstvé instalace se připojovaly normálně. Toto rozdělení, jedna skupina selhává a druhá je v pořádku na stejném účtu, je nejlevnější stopa, kterou dostanete.

Rozsah randomizace vymezte správně. Děje se při každém pokusu o připojení. Navázaný tunel znovu nepřekládá svůj koncový bod, nemění servery uprostřed relace a jednotlivé požadavky aplikací si nevybírají každý nového hostitele VPN. Znovu překládá až další pokus, proto relace, která funguje celé odpoledne, nic neříká o zítřejším ránu.

Co služba kontroluje při navázání tunelu

Client VPN vyžaduje, aby adresa, ke které jste připojeni, odpovídala adrese přeložené pro DNS název koncového bodu. Tento jediný požadavek vysvětluje několik selhání, která vypadají nesouvisele: vlastní DNS záznam ukazující jinam, vlastní frontend přesměrovávající na skutečnou adresu koncového bodu a profil přepsaný na surovou adresu. AWS dokumentuje kombinaci vlastního záznamu a předávání jako selhání u novějších klientů od AWS. Kontrola je úzká; není to rozsudek, že každý alias je zakázán.

Není to ani obecné pravidlo o VPN protokolech. Číselný remote je zcela platný v běžném nasazení OpenVPN a mnohá tak fungují. Omezení přichází ze spravovaného uspořádání, ne z protokolu pod ním.

Proto je uvolnění ověřování certifikátů špatný reflex. Pokud profil po záměně adresy selže, vypnutí ověřování serveru přesouvá chybu místo opravy překladu nebo požadavku na shodu adresy a zanechá klienta, který bude věřit čemukoli. Ponechte exportovanou CA, ověřování serveru a nastavení vzájemného ověřování přesně tak, jak přišly.

Povolené seznamy, výstup a soukromé DNS jsou tři oddělené problémy

Pravidlo firewallu, které musí povolit cíl před připojením notebooku, se týká vnějšího naslouchajícího rozhraní. Dejte vlastníkovi sítě název koncového bodu, transport a nakonfigurovaný port, pak se zeptejte, zda jejich kontrola umí sledovat DNS chování služby. Pravidlo držící jednu zachycenou adresu je snímek s nepsanou expirací. Pokud kontrola přijímá jen neměnné cíle, vyřešte tento rozdíl před zavedením, místo abyste tiše zakódovali odpověď.

Partner, který potřebuje pevnou zdrojovou adresu pro požadavky po navázání tunelu, má jiný požadavek: výstup. Co web vidí, závisí na trase aplikace a politice rozděleného tunelu, ne na adrese, ke které se klient připojil. Provoz v rozděleném tunelu se AWS nemusí vůbec dotknout.

Soukromé DNS uvnitř tunelu je třetí vrstva. Překladač předaný klientům odpovídá na interní názvy po připojení; veřejný koncový bod nemůže přeložit před vznikem tunelu. Selhání překladu koncového bodu a selhání překladu interní aplikace nastávají v různých fázích a jejich míchání vás pošle ke špatnému logu.

Adresní rodina patří do stejného seznamu. Odpověď IPv4 neříká nic o povolené cestě koncového bodu IPv6 nebo s dvojím zásobníkem, takže snímek pořízený v jedné rodině není důkazem pro druhou.

Zkontrolujte spojení, aniž byste cokoli fixovali

Začněte profilem tak, jak byl exportován, a přečtěte si, co skutečně žádá:

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

Pak porovnejte tři věci: název koncového bodu, který profil drží, adresu, kterou klient hlásí pro nový pokus, a na co se název překládá právě teď. Název, který se přeloží, dokazuje jen to, že záznam odpovídá; transport a ověřování jsou oddělené a koncový bod nemusí odpovídat na ping. Vlastní log klienta je jediným zdrojem pro prostřední položku, takže ho zachyťte během pokusu, ne po něm.

Adresa, která dnes odpovídá, je důkazem o dnešku; název je to, co služba udržuje platné. Zaznamenejte pozorování, pošlete ho tomu, kdo koncový bod vlastní, a nechte profil ukazovat na název.

Dva návyky, kterých se zbavit: vypínání kontrol certifikátů, abyste prošli zaseknutý handshake, a vršení štítků před název koncového bodu v naději, že jeden chytne. Štítek se přeloží přes divoký záznam, nebo je problém jinde. Pokud správně nakonfigurovaný profil stále selhává, pošlete přesný dotaz a událost připojení, ne delší název hostitele.

Než to uzavřete: profil stále nese exportovaný název koncového bodu, žádný soubor hosts adresu nefixuje, remote v logu klienta odpovídá aktuálnímu překladu a pravidlo firewallu jmenuje koncový bod, ne adresu. To je také stav, který předáte dalšímu člověku.