DNS AWS Client VPN-is: kasuta VPC resolverit, mitte alamvõrku
AWS Client VPN-i endpointi resolver on VPC peamine vahemik pluss kaks, mitte iga alamvõrk pluss kaks. Sea see, suuna see, seejärel kontrolli klienti.
Endpoint asub 10.0.8.0/24, seega peab resolver olema 10.0.8.2. See on kõige sagedamini kuuldud loogika ja see on kaks korda vale. Route 53 Resolver vastab VPC peamisel IPv4 vahemikul pluss kaks, mis VPC 10.0.0.0/16 puhul on 10.0.0.2, olenemata sellest, millist alamvõrku endpoint kasutab. Teine viga on vaiksem: õige aadressi endpointi panemine ei tähenda, et kliendi operatsioonisüsteem seda kunagi millegi kohta küsib. Mõlemad vead annavad sama sümptomi: nimede lahendamine töötab mõnel kliendil ja ebaõnnestub teistel.
Müüt algab alamvõrgu seosest
Seos puudutab seda, kus asuvad kliendiühenduste elastikud võrguliidesed, mitte seda, milline resolveri aadress eksisteerib. Endpointi alamvõrgud annavad klientidele aadressi VPC sees ja ükski neist ei kanna oma resolverit.
Kui need kaks ideed lahku lööd, lakkab arvutamine olemast müstiline ja tõrkeotsing liigub kliendi juurde, kuhu enamik neist juhtumitest tegelikult lõpeb.
Arvuta aadress VPC peamisest vahemikust
Võta VPC peamine IPv4 CIDR ja lisa võrguaadressile kaks. 10.0.0.0/16 annab 10.0.0.2, 172.31.0.0/16 annab 172.31.0.2 ja teisese vahemikuga VPC hoiab resolveri peamisel. Alamvõrk 10.0.8.0/24 selle VPC sees ei liiguta seda. Kirjuta aadress VPC ID kõrvale enne, kui endpointi puutud, sest number on VPC omadus, mitte ühenduse oma.
VPC vastab ka link-local aadressil 169.254.169.253. See aadress on VPC seest kättesaadav, kuid ei ole üldine marsruuditud sihtkoht tunneli teises otsas olevale sülearvutile.
Seega on kaks kehtivat resolveri aadressi ja kumbki neist ei ole alamvõrk pluss kaks.
Mida endpointi säte teeb ja mida mitte
Client VPN endpointil on DNS-serveri väljad ja kus konsool pakub VPC resolveri valikut, täidab see sama idee. Nende seadmine muudab seda, mida teenus ühenduse loomisel klientidele edastab. See ei muuda seda, mida haldamata OpenVPN klient selle väärtusega teeb, sest klient peab selle ikkagi operatsioonisüsteemi rakendama. Sellest lõhest tuleb «töötab minu Macis, aga mitte Linuxi masinas».
Linuxis kuulub resolveri integratsioon ühendusehaldurile, mitte kasutajale. /etc/resolv.conf käsitsi muutmine tõestab, et aadress töötab ühe sessiooni jaoks, ja siis kaob see taasühendamisel — seetõttu tulevad paljud parandatud juhtumid järgmisel hommikul tagasi.
Kontrolli pärast ühendamist kliendil aktiivset resolverit, mitte endpointi seadistuslehte.
Split tunneling võib õige resolveri nurjata
Split tunnelinguga kasutatakse ainult tunnelisse lükatud marsruute. Kui resolveri aadress ei ole marsruudiga kaetud, väljub päring kohaliku liidese kaudu ja vastab sinu koduruuter. Aadress endpointis on endiselt õige ja otsing endiselt ebaõnnestub. Lisa resolveri marsruut ja proovi uuesti.
Kattuvad kohalikud vahemikud annavad sama tulemuse vastikumas vormis: päringule vastatakse, lihtsalt vale serveri poolt.
Ära ava Amazon DNS-i aadressi jaoks turvagruppe
Otsingute aegumisel on instinkt lisada reegel, mis lubab UDP 53 resolveri aadressile. AWS dokumenteerib, et turvagrupid ja võrgu ACL-id ei filtreeri Amazon DNS liiklust nii, nagu nad filtreerivad liiklust oma DNS-i instantsi juurde. Nende reeglite avamine ei muuda VPC resolveri jaoks midagi ja laiendab piiri põhjuseta. Resolver, mida ise jooksutad, on teine juhtum ja vajab tõesti oma reegleid.
Kui mõlemad sinu disainis esinevad, kontrolli enne reegli muutmist, millele klient tegelikult osutab.
Kontrolli teed ja mõõda siis midagi muud
Lahenda avalik nimi, lahenda privaatne nimi, mis on registreeritud VPC-ga seotud privaatses hostitud tsoonis, ja loe nende vahel kliendi aktiivset resolverit. See järjestus eristab «resolveri aadress on vale» olukorrast «tsoon ei ole seotud» ja olukorrast «klient eiras seadet». Igal on erinev parandus ja ükski neist ei ole läbilaskevõime probleem.
Edukas otsing ei ütle midagi püsiva ülekandekiiruse kohta, seega hoia need kaks vestlust aruandes eraldi.