DNS v AWS Client VPN: použite resolver VPC, nie podsiete

Endpoint je v 10.0.8.0/24, takže resolver musí byť 10.0.8.2. To je úvaha, ktorú počúvam najčastejšie, a je dvakrát nesprávna. Route 53 Resolver odpovedá na primárnom rozsahu IPv4 VPC plus dva, čo je pre VPC 10.0.0.0/16 adresa 10.0.0.2, bez ohľadu na to, ktorú podsieť endpoint používa. Druhá chyba je tichšia: správna adresa v endpointe neznamená, že sa na ňu operačný systém klienta niekedy vôbec opýta. Obe chyby dávajú rovnaký príznak: preklad mien funguje u niektorých klientov a u iných zlyháva.

Mýtus začína pri asociácii podsiete

Asociácia sa týka toho, kde žijú elastické sieťové rozhrania pre klientske spojenia, nie toho, ktorá adresa resolvera existuje. Podsiete endpointu dávajú klientom adresu vnútri VPC a žiadna z nich nenesie vlastný resolver.

Keď obe myšlienky oddelíte, aritmetika prestane byť záhadná a riešenie problémov sa presunie ku klientovi, kde väčšina týchto prípadov skutočne končí.

Vypočítajte adresu z primárneho rozsahu VPC

Vezmite primárny IPv4 CIDR VPC a k sieťovej adrese pripočítajte dva. 10.0.0.0/16 dáva 10.0.0.2, 172.31.0.0/16 dáva 172.31.0.2 a VPC so sekundárnym rozsahom drží resolver na primárnom. Podsieť 10.0.8.0/24 v tomto VPC s ním nepohne. Napíšte adresu vedľa ID VPC, skôr než sa dotknete endpointu, pretože číslo je vlastnosť VPC, nie spojenia.

VPC odpovedá aj na link-local adrese 169.254.169.253. Táto adresa je dostupná zvnútra VPC, ale nie je všeobecným smerovaným cieľom pre notebook na druhej strane tunela.

Existujú teda dve platné adresy resolvera a ani jedna z nich nie je podsieť plus dva.

Čo nastavenie endpointu robí a čo nie

Endpoint Client VPN má polia pre DNS server a tam, kde konzola ponúka voľbu resolvera VPC, vyplní rovnakú myšlienku. Ich nastavenie mení to, čo služba odovzdáva klientom pri nadväzovaní spojenia. Nemení to, čo s touto hodnotou robí neriadený klient OpenVPN, pretože klient ju stále musí aplikovať do operačného systému. Z tejto medzery pochádza „funguje to na mojom Macu, ale nie na Linuxe“.

V Linuxe integráciu resolvera vlastní správca pripojení, nie používateľ. Ručná úprava /etc/resolv.conf dokáže, že adresa funguje pre jednu reláciu, a potom pri opätovnom pripojení zmizne — preto sa toľko opravených prípadov vracia ďalšie ráno.

Po pripojení skontrolujte aktívny resolver na klientovi, nie stránku konfigurácie endpointu.

Split tunneling môže poraziť správny resolver

Pri split tunelovaní sa používajú len trasy vložené do tunela. Ak adresa resolvera nie je pokrytá trasou, dotaz odíde cez lokálne rozhranie a odpovie domáci router. Adresa v endpointe je stále správna a vyhľadanie stále zlyháva. Pridajte trasu pre resolver a skúste to znova.

Prekrývajúce sa lokálne rozsahy dávajú rovnaký výsledok škaredším spôsobom: dotaz dostane odpoveď, len od nesprávneho servera.

Neotvárajte security groups pre adresu Amazon DNS

Inštinkt pri vypršaní vyhľadávania je pridať pravidlo povoľujúce UDP 53 na adresu resolvera. AWS dokumentuje, že security groups a sieťové ACL nefiltrujú prevádzku Amazon DNS tak, ako filtrujú prevádzku na vlastnú inštanciu DNS. Otvorenie týchto pravidiel nič nemení pre resolver VPC a rozširuje hranicu bez dôvodu. Resolver, ktorý prevádzkujete sami, je iný prípad a naozaj potrebuje vlastné pravidlá.

Ak sa v návrhu objavujú obe, pred úpravou akéhokoľvek pravidla skontrolujte, na ktoré klient skutočne mieri.

Overte cestu a potom merajte niečo iné

Preložte verejné meno, preložte súkromné meno registrované v privátnej hosťovanej zóne pridruženej k VPC a medzi tým prečítajte aktívny resolver klienta. Táto postupnosť oddeľuje „adresa resolvera je nesprávna“ od „zóna nie je pridružená“ a od „klient nastavenie ignoroval“. Každý má inú opravu a žiadny nie je problémom priepustnosti.

Úspešné vyhľadanie nič nehovorí o trvalej rýchlosti prenosu, takže tieto dve konverzácie pri reportovaní držte oddelene.