DNS u AWS Client VPN: použijte resolver VPC, ne podsíť

Endpoint je v 10.0.8.0/24, takže resolver musí být 10.0.8.2. To je úvaha, kterou slýchám nejčastěji, a je dvakrát špatná. Route 53 Resolver odpovídá na primárním rozsahu IPv4 VPC plus dva, což je pro VPC 10.0.0.0/16 adresa 10.0.0.2, bez ohledu na to, kterou podsíť endpoint používá. Druhá chyba je tišší: správná adresa v endpointu neznamená, že se na ni operační systém klienta vůbec někdy zeptá. Obě chyby dávají stejný příznak: překlad jmen funguje u některých klientů a u jiných selhává.

Mýtus začíná u asociace podsítě

Asociace se týká toho, kde žijí elastická síťová rozhraní pro klientská spojení, ne toho, která adresa resolveru existuje. Podsítě endpointu dávají klientům adresu uvnitř VPC a žádná z nich nenese vlastní resolver.

Jakmile obě myšlenky oddělíte, aritmetika přestane být záhadná a řešení problémů se přesune ke klientovi, kde většina těchto případů skutečně končí.

Vypočítejte adresu z primárního rozsahu VPC

Vezměte primární IPv4 CIDR VPC a k síťové adrese přičtěte dva. 10.0.0.0/16 dává 10.0.0.2, 172.31.0.0/16 dává 172.31.0.2 a VPC se sekundárním rozsahem drží resolver na primárním. Podsíť 10.0.8.0/24 v této VPC s ním nepohne. Napište adresu vedle ID VPC, než se endpointu dotknete, protože číslo je vlastnost VPC, ne spojení.

VPC odpovídá také na link-local adrese 169.254.169.253. Tato adresa je dostupná zevnitř VPC, ale není obecným směrovaným cílem pro notebook na druhé straně tunelu.

Existují tedy dvě platné adresy resolveru a ani jedna z nich není podsíť plus dva.

Co nastavení endpointu dělá a co ne

Endpoint Client VPN má pole pro DNS server a tam, kde konzole nabízí volbu resolveru VPC, vyplní stejnou myšlenku. Jejich nastavení mění to, co služba předává klientům při navazování spojení. Nemění to, co s touto hodnotou dělá neřízený klient OpenVPN, protože klient ji stále musí aplikovat do operačního systému. Z této mezery pochází „funguje to na mém Macu, ale ne na Linuxu“.

V Linuxu integraci resolveru vlastní správce připojení, ne uživatel. Ruční úprava /etc/resolv.conf dokáže, že adresa funguje pro jednu relaci, a pak při opětovném připojení zmizí — proto se tolik opravených případů vrací další ráno.

Po připojení zkontrolujte aktivní resolver na klientu, ne stránku konfigurace endpointu.

Split tunneling může porazit správný resolver

Při split tunelování se používají jen trasy vložené do tunelu. Pokud adresa resolveru není pokryta trasou, dotaz odejde přes lokální rozhraní a odpoví domácí router. Adresa v endpointu je stále správná a vyhledání stále selhává. Přidejte trasu pro resolver a zkuste to znovu.

Překrývající se lokální rozsahy dávají stejný výsledek ošklivěji: dotaz dostane odpověď, jen od špatného serveru.

Neotvírejte security groups pro adresu Amazon DNS

Instinkt při vypršení dotazů je přidat pravidlo povolující UDP 53 na adresu resolveru. AWS dokumentuje, že security groups a síťové ACL nefiltrují provoz Amazon DNS tak, jak filtrují provoz na vlastní instanci DNS. Otevření těchto pravidel nic nemění pro resolver VPC a rozšiřuje hranici bez důvodu. Resolver, který provozujete sami, je jiný případ a vlastní pravidla skutečně potřebuje.

Pokud se v návrhu objevují oba, před úpravou jakéhokoli pravidla zkontrolujte, na který z nich klient skutečně míří.

Ověřte cestu a pak měřte něco jiného

Přeložte veřejné jméno, přeložte soukromé jméno registrované v privátní hostované zóně přidružené k VPC a mezi tím přečtěte aktivní resolver klienta. Tato posloupnost odděluje „adresa resolveru je špatná“ od „zóna není přidružená“ a od „klient nastavení ignoroval“. Každý má jinou opravu a žádný není problém propustnosti.

Úspěšné vyhledání nic neříká o trvalé rychlosti přenosu, takže tyto dvě konverzace při reportování držte oddělené.