AWS Client VPN-DNS: gebruik die VPC-resolver, nie die subnet nie

Die eindpunt sit in 10.0.8.0/24, dus moet die resolver 10.0.8.2 wees. Dit is die redenasie wat ek die meeste hoor, en dit is twee keer verkeerd. Route 53 Resolver antwoord op die primêre VPC IPv4-reeks plus twee, wat vir ’n VPC van 10.0.0.0/16 10.0.0.2 is, ongeag watter subnet die eindpunt gebruik. Die tweede fout is stiller: om die regte adres in die eindpunt te sit beteken nie dat die kliënt se bedryfstelsel ooit iets daaraan vra nie. Albei foute gee dieselfde simptoom: naamoplossing werk vir sommige kliënte en faal vir ander.

Die mite begin by die subnet-assosiasie

Assosiasie gaan oor waar die elastiese netwerkkoppelvlakke vir kliëntverbindings woon, nie oor watter resolveradres bestaan nie. Die eindpunt se subnette gee kliënte ’n adres binne die VPC, en elkeen dra nie sy eie resolver nie.

Sodra jy daardie twee idees skei, is die rekenkunde nie meer raaiselagtig nie, en die probleemoplossing skuif na die kliënt, waar die meeste van hierdie gevalle werklik eindig.

Bereken die adres uit die primêre VPC-reeks

Neem die VPC se primêre IPv4-CIDR en tel twee by die netwerkadres. 10.0.0.0/16 gee 10.0.0.2, 172.31.0.0/16 gee 172.31.0.2, en ’n VPC met ’n sekondêre reeks hou die resolver op die primêre een. ’n Subnet van 10.0.8.0/24 binne daardie VPC skuif dit nie. Skryf die adres langs die VPC-ID voordat jy aan die eindpunt raak, want die nommer is ’n eienskap van die VPC en nie van die verbinding nie.

Die VPC antwoord ook op die link-local adres 169.254.169.253. Daardie adres is binne die VPC bereikbaar, maar dit is nie ’n algemene geroteerde bestemming vir ’n skootrekenaar aan die ander kant van ’n tonnel nie.

Daar is dus twee geldige resolveradresse, en nie een van hulle is die subnet plus twee nie.

Wat die eindpuntinstelling doen en wat nie

Die Client VPN-eindpunt het DNS-bedienervelde, en waar die konsole ’n VPC-resolver-opsie bied, vul dit dieselfde idee in. Om hulle te stel verander wat die diens tydens verbindingsopstelling aan kliënte gee. Dit verander nie wat ’n onbestuurde OpenVPN-kliënt met daardie waarde doen nie, want die kliënt moet dit steeds op die bedryfstelsel toepas. Daardie gaping is waar “dit werk op my Mac maar nie op die Linux-boks nie” vandaan kom.

Op Linux word die resolverintegrasie deur die verbindingsbestuurder besit eerder as deur die gebruiker. Om /etc/resolv.conf met die hand te redigeer bewys dat die adres vir een sessie werk, en dan verdwyn dit by herverbinding — daarom kom so baie reggemaakte gevalle die volgende oggend terug.

Kontroleer die aktiewe resolver op die kliënt nadat jy verbind het, nie die eindpunt se konfigurasiebladsy nie.

Split-tunneling kan ’n korrekte resolver verydel

Met split-tunneling word net roetes wat in die tonnel gestoot word, gebruik. As die resolveradres nie deur ’n roete gedek word nie, verlaat die navraag die plaaslike koppelvlak en word dit deur jou tuisroeteerder beantwoord. Die adres in die eindpunt is steeds korrek en die opsoek faal steeds. Voeg die roete vir die resolver by en toets weer.

Oorvleuelende plaaslike reekse lewer dieselfde resultaat op ’n nareder manier: die navraag word beantwoord, net deur die verkeerde bediener.

Moet nie sekuriteitsgroepe vir die Amazon DNS-adres oopmaak nie

Die instink wanneer opsoeke tyd uitloop, is om ’n reël by te voeg wat UDP 53 na die resolveradres toelaat. AWS dokumenteer dat sekuriteitsgroepe en netwerk-ACL’s nie Amazon DNS-verkeer filtreer soos hulle verkeer na ’n pasgemaakte DNS-instansie filtreer nie. Om daardie reëls oop te maak verander niks vir die VPC-resolver nie en verbreed die grens sonder rede. ’n Resolver wat jy self bedryf is ’n ander geval en het wel sy eie reëls nodig.

As albei in jou ontwerp voorkom, kyk na watter een die kliënt werklik gerig is voordat jy enige reël wysig.

Verifieer die pad en meet dan iets anders

Los ’n publieke naam op, los ’n private naam op wat in ’n private gehoste sone geregistreer is wat met die VPC geassosieer is, en lees die kliënt se aktiewe resolver tussen die twee. Daardie volgorde skei “die resolveradres is verkeerd” van “die sone is nie geassosieer nie” van “die kliënt het die instelling geïgnoreer”. Elkeen het ’n ander oplossing, en nie een van hulle is ’n deursetprobleem nie.

’n Suksesvolle opsoek sê niks oor volgehoue oordragspoed nie, so hou daardie twee gesprekke apart wanneer jy terugrapporteer.