AWS Client VPN ja DNS: käytä VPC:n resolveria, älä aliverkkoa

Endpoint on 10.0.8.0/24-verkossa, joten resolverin on oltava 10.0.8.2. Tämä on yleisin kuulemani perustelu, ja se on väärin kahdesti. Route 53 Resolver vastaa VPC:n ensisijaisella IPv4-alueella plus kaksi, mikä VPC:llä 10.0.0.0/16 on 10.0.0.2 riippumatta siitä, mitä aliverkkoa endpoint käyttää. Toinen virhe on hiljaisempi: oikean osoitteen laittaminen endpointiin ei tarkoita, että asiakkaan käyttöjärjestelmä koskaan kysyisi siltä mitään. Molemmat virheet tuottavat saman oireen: nimien selvitys toimii joillakin asiakkaille ja epäonnistuu toisilla.

Myytti alkaa aliverkon liitoksesta

Liitos koskee sitä, missä asiakasyhteyksien elastiset verkkorajapinnat sijaitsevat, ei sitä, mikä resolver-osoite on olemassa. Endpointin aliverkot antavat asiakkaille osoitteen VPC:n sisällä, eikä jokaisella ole omaa resolveriaan.

Kun erotat nämä kaksi ajatusta, aritmetiikka lakkaa olemasta mystistä ja vianetsintä siirtyy asiakkaaseen, jonne useimmat näistä tapauksista todella päättyvät.

Laske osoite VPC:n ensisijaisesta alueesta

Ota VPC:n ensisijainen IPv4-CIDR ja lisää verkkosoitteeseen kaksi. 10.0.0.0/16 antaa 10.0.0.2, 172.31.0.0/16 antaa 172.31.0.2, ja toissijaisen alueen VPC pitää resolverin ensisijaisella. Aliverkko 10.0.8.0/24 sen VPC:n sisällä ei siirrä sitä. Kirjoita osoite VPC-tunnuksen viereen ennen kuin kosket endpointiin, koska luku on VPC:n ominaisuus eikä yhteyden.

VPC vastaa myös link-local-osoitteessa 169.254.169.253. Osoite on saavutettavissa VPC:n sisältä, mutta se ei ole yleinen reititetty kohde tunnelin toisessa päässä olevalle kannettavalle.

Siis kelvollisia resolver-osoitteita on kaksi, eikä kumpikaan niistä ole aliverkko plus kaksi.

Mitä endpointin asetus tekee ja mitä ei

Client VPN -endpointissa on DNS-palvelinkentät, ja kun konsoli tarjoaa VPC-resolver-vaihtoehdon, se täyttää saman idean. Niiden asettaminen muuttaa sitä, mitä palvelu antaa asiakkaille yhteyden muodostuksen aikana. Se ei muuta sitä, mitä hallitsematon OpenVPN-asiakas tekee arvolla, koska asiakkaan täytyy silti soveltaa se käyttöjärjestelmään. Tästä aukosta tulee ”toimii Macissani mutta ei Linux-koneessa”.

Linuxissa resolverin integrointi kuuluu yhteyksien hallinnalle eikä käyttäjälle. /etc/resolv.conf tiedoston muokkaaminen käsin todistaa, että osoite toimii yhden istunnon ajan ja katoaa sitten uudelleenyhdistettäessä — siksi niin moni korjattu tapaus palaa seuraavana aamuna.

Tarkista aktiivinen resolver asiakkaasta yhteyden muodostamisen jälkeen, älä endpointin asetussivua.

Split tunneling voi kumota oikean resolverin

Split tunnelingissa käytetään vain tunneliin työnnettyjä reittejä. Jos resolver-osoite ei ole reitin kattama, kysely lähtee paikallisen rajapinnan kautta ja kotireitittimesi vastaa siihen. Osoite endpointissa on edelleen oikein ja haku epäonnistuu edelleen. Lisää reitti resolverille ja testaa uudelleen.

Päällekkäiset paikalliset alueet antavat saman tuloksen ikävämmällä tavalla: kyselyyn vastataan, mutta väärästä palvelimesta.

Älä avaa security group -sääntöjä Amazon DNS -osoitteelle

Vaisto, kun haut aikakatkaistaan, on lisätä sääntö, joka sallii UDP 53 -liikenteen resolver-osoitteeseen. AWS dokumentoi, että security groupit ja verkon ACL:t eivät suodata Amazon DNS -liikennettä samalla tavalla kuin liikennettä omaan DNS-instanssiin. Näiden sääntöjen avaaminen ei muuta mitään VPC-resolverin kannalta ja laajentaa rajaa syyttä. Itse ylläpitämäsi resolver on eri tapaus ja tarvitsee todella omat sääntönsä.

Jos molemmat esiintyvät suunnittelussasi, tarkista, kumpaan asiakas todella osoittaa, ennen kuin muokkaat mitään sääntöä.

Varmista polku ja mittaa sitten jotain muuta

Selvitä julkinen nimi, selvitä yksityinen nimi, joka on rekisteröity VPC:hen liitettyyn yksityiseen hosted zone -alueeseen, ja lue asiakkaan aktiivinen resolver näiden välissä. Tämä järjestys erottaa ”resolver-osoite on väärä” tilanteesta ”vyöhykettä ei ole liitetty” ja tilanteesta ”asiakas jätti asetuksen huomiotta”. Jokaisella on eri korjaus, eikä mikään niistä ole läpäisykyvyn ongelma.

Onnistunut haku ei kerro mitään pysyvästä siirtonopeudesta, joten pidä nämä kaksi keskustelua erillään raportoidessasi.