AWS Client VPN och DNS: använd VPC-resolvern, inte subnätet

Endpointen ligger i 10.0.8.0/24, så resolvern måste vara 10.0.8.2. Det är resonemanget jag hör oftast, och det är fel två gånger. Route 53 Resolver svarar på VPC:ns primära IPv4-område plus två, vilket för en VPC på 10.0.0.0/16 är 10.0.0.2, oavsett vilket subnät endpointen använder. Det andra felet är tystare: att sätta rätt adress i endpointen betyder inte att klientens operativsystem någonsin frågar den om något. Båda felen ger samma symptom: namnmatchning fungerar för vissa klienter och misslyckas för andra.

Myten börjar vid subnätskopplingen

Kopplingen handlar om var de elastiska nätverksgränssnitten för klientanslutningar bor, inte om vilken resolveradress som finns. Endpointens subnät ger klienterna en adress inne i VPC:n, och de bär inte var sin resolver.

När du skiljer de två idéerna slutar aritmetiken vara mystisk och felsökningen flyttar till klienten, där de flesta av dessa ärenden faktiskt slutar.

Beräkna adressen från VPC:ns primära område

Ta VPC:ns primära IPv4-CIDR och lägg till två på nätverksadressen. 10.0.0.0/16 ger 10.0.0.2, 172.31.0.0/16 ger 172.31.0.2, och en VPC med ett sekundärt område behåller resolvern på det primära. Ett subnät på 10.0.8.0/24 inne i den VPC:n flyttar den inte. Skriv adressen bredvid VPC-ID:t innan du rör endpointen, eftersom talet är en egenskap hos VPC:n och inte hos anslutningen.

VPC:n svarar också på link-local-adressen 169.254.169.253. Den adressen är nåbar inifrån VPC:n, men den är inte ett vanligt routat mål för en laptop i andra änden av en tunnel.

Så det finns två giltiga resolveradresser, och ingen av dem är subnätet plus två.

Vad endpoint-inställningen gör och inte gör

Client VPN-endpointen har DNS-serverfält, och där konsolen erbjuder ett VPC-resolver-alternativ fyller den i samma idé. Att ställa in dem ändrar vad tjänsten ger klienterna vid anslutningsuppbyggnaden. Det ändrar inte vad en icke-hanterad OpenVPN-klient gör med värdet, eftersom klienten fortfarande måste tillämpa det i operativsystemet. Det gapet är där «det funkar på min Mac men inte på Linux-burken» kommer ifrån.

På Linux ägs resolverintegrationen av anslutningshanteraren och inte av användaren. Att redigera /etc/resolv.conf för hand bevisar att adressen fungerar för en session och sedan försvinner vid återanslutning — därför kommer så många lagade ärenden tillbaka nästa morgon.

Kontrollera den aktiva resolvern på klienten efter anslutning, inte endpointens konfigurationssida.

Split tunnelling kan slå ut en korrekt resolver

Med split tunnelling används bara rutter som skjuts in i tunneln. Om resolveradressen inte täcks av en rutt lämnar frågan det lokala gränssnittet och besvaras av din hemmarouter. Adressen i endpointen är fortfarande korrekt och uppslaget misslyckas fortfarande. Lägg till rutten för resolvern och testa igen.

Överlappande lokala områden ger samma resultat på ett mer irriterande sätt: frågan besvaras, bara av fel server.

Öppna inga säkerhetsgrupper för Amazon DNS-adressen

Instinkten när uppslag tar slut på tid är att lägga till en regel som tillåter UDP 53 till resolveradressen. AWS dokumenterar att säkerhetsgrupper och nätverks-ACL:er inte filtrerar Amazon DNS-trafik som de filtrerar trafik till en egen DNS-instans. Att öppna de reglerna ändrar inget för VPC-resolvern och vidgar gränsen utan skäl. En resolver du driver själv är ett annat fall och behöver faktiskt egna regler.

Om båda finns i din design, kontrollera vilken klienten faktiskt pekar på innan du redigerar någon regel.

Verifiera vägen och mät sedan något annat

Slå upp ett offentligt namn, slå upp ett privat namn som registrerats i en privat hostad zon kopplad till VPC:n, och läs klientens aktiva resolver mellan de två. Den ordningen skiljer «resolveradressen är fel» från «zonen är inte kopplad» och från «klienten ignorerade inställningen». Varje fall har sin egen åtgärd, och ingen av dem är ett genomströmningsproblem.

En lyckad uppslagning säger ingenting om varaktig överföringshastighet, så håll de två samtalen åtskilda när du rapporterar.