AWS Client VPN DNS: izmantojiet VPC resolveri, nevis apakštīklu

Endpoint atrodas 10.0.8.0/24, tāpēc resolverim jābūt 10.0.8.2. Šis ir visbiežāk dzirdētais pamatojums, un tas ir divreiz nepareizs. Route 53 Resolver atbild uz VPC galvenā IPv4 diapazona plus divi, kas VPC 10.0.0.0/16 gadījumā ir 10.0.0.2, neatkarīgi no tā, kuru apakštīklu endpoint izmanto. Otrā kļūda ir klusāka: pareizas adreses ievietošana endpointā nenozīmē, ka klienta operētājsistēma kādreiz to kaut ko jautās. Abas kļūdas dod vienu un to pašu simptomu: vārdu atrisināšana darbojas dažiem klientiem un neizdodas citiem.

Mīts sākas ar apakštīkla saistīšanu

Saistīšana attiecas uz to, kur atrodas elastīgās tīkla saskarnes klientu savienojumiem, nevis uz to, kāda resolvera adrese pastāv. Endpointa apakštīkli dod klientiem adresi VPC iekšienē, un neviens no tiem nenes savu resolveri.

Kad šīs divas idejas atdala, aritmētika pārstāj būt noslēpumaina, un problēmu meklēšana pāriet uz klientu, kur vairums šo gadījumu patiešām beidzas.

Aprēķiniet adresi no VPC galvenā diapazona

Paņemiet VPC galveno IPv4 CIDR un pievienojiet divi tīkla adresei. 10.0.0.0/16 dod 10.0.0.2, 172.31.0.0/16 dod 172.31.0.2, un VPC ar sekundāro diapazonu patur resolveri uz galvenā. Apakštīkls 10.0.8.0/24 šajā VPC to neizkustina. Pierakstiet adresi blakus VPC ID, pirms aiztiekat endpointu, jo skaitlis ir VPC īpašība, nevis savienojuma.

VPC atbild arī uz link-local adresi 169.254.169.253. Šī adrese ir sasniedzama no VPC iekšienes, bet tā nav vispārējs maršrutēts galamērķis klēpjdatoram tuneļa otrā galā.

Tātad ir divas derīgas resolvera adreses, un neviena no tām nav apakštīkls plus divi.

Ko dara endpointa iestatījums un ko ne

Client VPN endpointam ir DNS servera lauki, un tur, kur konsolē tiek piedāvāta VPC resolvera opcija, tā aizpilda to pašu ideju. To iestatīšana maina to, ko pakalpojums nodod klientiem savienojuma izveides laikā. Tas nemaina to, ko neapkalpots OpenVPN klients dara ar šo vērtību, jo klientam tā vēl jāpiemēro operētājsistēmā. No šīs plaisas nāk «strādā manā Mac, bet ne Linux mašīnā».

Linux resolver integrācija pieder savienojumu pārvaldniekam, nevis lietotājam. /etc/resolv.conf manuāla labošana pierāda, ka adrese strādā vienai sesijai un pēc tam pazūd atkārtotas pieslēgšanās laikā — tāpēc tik daudz salabotu gadījumu atgriežas nākamajā rītā.

Pēc pieslēgšanās pārbaudiet aktīvo resolveri klientā, nevis endpointa konfigurācijas lapu.

Split tunneling var uzveikt pareizu resolveri

Ar split tunneling tiek izmantoti tikai tunelī iespiestie maršruti. Ja resolvera adresi nesedz neviens maršruts, vaicājums iziet pa lokālo saskarni un atbild jūsu mājas maršrutētājs. Adrese endpointā joprojām ir pareiza, un meklēšana joprojām neizdodas. Pievienojiet maršrutu resolverim un pārbaudiet vēlreiz.

Pārklājošies lokālie diapazoni dod to pašu rezultātu nepatīkamākā veidā: vaicājums saņem atbildi, tikai no nepareizā servera.

Neatveriet security groups Amazon DNS adresei

Instinkts, kad meklēšana pārsniedz laiku, ir pievienot noteikumu, kas atļauj UDP 53 uz resolvera adresi. AWS dokumentē, ka security groups un tīkla ACL nefiltrē Amazon DNS datplūsmu tā, kā filtrē datplūsmu uz pašu DNS instanci. Šo noteikumu atvēršana neko nemaina VPC resolverim un bez iemesla paplašina robežu. Paša uzturēts resolveris ir cits gadījums, un tam tiešām vajag savus noteikumus.

Ja abi parādās jūsu dizainā, pirms rediģējat jebkuru noteikumu, pārbaudiet, uz kuru klients patiešām ir vērsts.

Pārbaudiet ceļu, tad mēriet ko citu

Atrisiniet publisku vārdu, atrisiniet privātu vārdu, kas reģistrēts privātā mitinātā zonā, kas saistīta ar VPC, un starp tiem nolasiet klienta aktīvo resolveri. Šī secība atdala «resolvera adrese ir nepareiza» no «zona nav saistīta» un no «klients ignorēja iestatījumu». Katram ir cits labojums, un neviens no tiem nav caurlaidspējas problēma.

Veiksmīga meklēšana neko nepasaka par ilgstošu pārsūtīšanas ātrumu, tāpēc atskaitē turiet šīs divas sarunas atsevišķi.