AWS Client VPN galapunkta DNS: kāpēc atrisinātā IP fiksēšana neizdodas

Pagājušajā nedēļā dig +short deva vienu adresi jūsu AWS Client VPN profila galapunkta nosaukumam, un tunelis savienojās. Šonedēļ tas pats profils jūsu klēpjdatorā paliek pie 'Connecting', kamēr kolēģa neskartā kopija joprojām darbojas. Nekas netika bloķēts un sertifikāts nebeidzās. Kāds aizstāja galapunkta resursdatora nosaukumu ar to atrisināto adresi, un pakalpojums tur vairs neatbild. Eksportētais nosaukums ir tā daļa, kas veidota, lai izturētu šīs izmaiņas.

Profila nosaukums var nebūt tas nosaukums, par kuru tiek vaicāts

Profili, kas eksportēti no Client VPN, parasti satur remote-random-hostname. Kad šī opcija ir ieslēgta, klients izveido vienreizēju etiķeti, pievieno to galapunkta nosaukumam ar punktu un atrisina apvienoto nosaukumu. Wildcard ieraksts galapunkta zonā atbild uz jebkuru etiķeti, tāpēc izdomāts prefikss joprojām tiek atrisināts un tāpēc šis triks paliek neredzams, kad mēģināt atkārtot vaicājumu ar roku.

Tātad, kad ielīmējat galapunkta nosaukumu terminālī un saņemat atbildi, jūs esat atrisinājis citu nosaukumu nekā to, ko klients izmanto savienošanās laikā. Šī neatbilstība nav defekts, kas jālabo profilā. Etiķete tiek ģenerēta no jauna apzināti: opcija neļauj kešatmiņām turēt novecojušu atbildi, un tā nekad neidentificē jūsu mašīnu vai sesiju.

Esmu saskāries ar saderības gadījumu, kad klients opciju pilnībā ignorē. AWS dokumentē risinājumu: saglabājiet īsto galapunkta nosaukumu un pievienojiet priekšā nejaušu virkni un punktu, uzskatot to par nosaukumu shēmu, nevis ielīmējamu vērtību. To piemērot vecam klientam ir saprātīgi; iekodēt prefiksēto virkni kā galapunktu nav.

Kāpēc saglabātā atbilde nevar palikt pareiza

Client VPN galapunkta adreses pārvalda AWS, un tās laika gaitā mainās, ko labāko prakšu dokumentācija saka tieši. Uzņemtā atbilde ir viena atrisinājuma momentuzņēmums. Profils, kas to iekodē, kļūst par profilu, kas vērsts uz ekspluatācijas pārtrauktu resursdatoru, tiklīdz pakalpojums pārvietojas, un kļūme reti izskatās kā DNS: jūs saņemat savienojuma taimautu vai iesprūdušu handshake, tāpēc cilvēki dzenas pēc maršrutēšanas un sertifikātiem.

Tā pati atbilde /etc/hosts manto to pašu derīguma termiņu ar papildu problēmu. hosts ieraksts pārdzīvo pārstartēšanas, atkārtotus eksportus un 'pārinstalē klientu' labojumus, tāpēc kļūme atgriežas katru reizi, kad adrese pārvietojas. Esmu redzējis, kā viens nedēļām ilgi gulēja nekaitīgi un pēc tam izslēdza katru mašīnu, kas to nesa, kamēr svaigas instalācijas savienojās normāli. Šis sadalījums, viena grupa neizdodas un otra tajā pašā kontā ir kārtībā, ir lētākais pavediens, ko iegūsiet.

Pareizi ierobežojiet randomizāciju. Tā notiek katram savienojuma mēģinājumam. Izveidots tunelis atkārtoti neatrisina savu galapunktu, nemaina serverus sesijas vidū, un atsevišķi lietotņu pieprasījumi katrs neizvēlas jaunu VPN resursdatoru. Tikai nākamais mēģinājums atkal atrisina, tāpēc sesija, kas strādā visu pēcpusdienu, neko ne saka par rītdienas rītu.

Ko pakalpojums pārbauda, kad tunelis paceļas

Client VPN pieprasa, lai adrese, ar kuru esat savienots, atbilstu adresei, kas atrisināta galapunkta DNS nosaukumam. Šī viena prasība izskaidro vairākas kļūmes, kas izskatās nesaistītas: pielāgots DNS ieraksts, kas norāda citur, pielāgots frontend, kas pārsūta uz īsto galapunkta adresi, un profils, kas pārrakstīts uz neapstrādātu adresi. AWS dokumentē pielāgota ieraksta un pārsūtīšanas kombināciju kā kļūmi ar jaunākiem AWS klientiem. Pārbaude ir šaura; tas nav spriedums, ka katrs aizstājvārds ir aizliegts.

Tas nav arī vispārīgs noteikums par VPN protokoliem. Skaitlisks remote ir pilnīgi derīgs parastā OpenVPN ieviešanā, un daudzi tā strādā. Ierobežojums nāk no pārvaldītā izkārtojuma, nevis no protokola zem tā.

Tas padara sertifikātu pārbaudes mīkstināšanu par nepareizu refleksu. Ja profils neizdodas pēc adreses maiņas, servera pārbaudes izslēgšana pārvieto kļūdu, nevis salabo atrisinājumu vai adreses atbilstības prasību, un atstāj klientu, kas uzticēsies jebkam. Saglabājiet eksportēto CA, servera pārbaudi un savstarpējās autentifikācijas iestatījumus tieši tādus, kādi tie atnāca.

Atļauju saraksti, izeja un privātais DNS ir trīs atsevišķas problēmas

Ugunsmūra noteikums, kam jāatļauj galamērķis pirms klēpjdatora savienošanās, attiecas uz ārējo klausītāju. Dodiet tīkla īpašniekam galapunkta nosaukumu, transportu un konfigurēto portu, pēc tam jautājiet, vai viņu kontrole var sekot pakalpojuma DNS uzvedībai. Noteikums, kas tur vienu uzņemtu adresi, ir momentuzņēmums ar neuzrakstītu derīguma termiņu. Ja kontrole pieņem tikai nemainīgus galamērķus, atrisiniet šo plaisu pirms ieviešanas, nevis klusi iekodējiet atbildi.

Partnerim, kam vajadzīga fiksēta avota adrese pieprasījumiem pēc tuneļa pacelšanas, ir cita prasība: izeja. To, ko redz vietne, nosaka lietotnes maršruts un sadalītā tuneļa politika, nevis adrese, ar kuru savienojās klients. Sadalītā tuneļa trafiks var vispār nepieskarties AWS.

Privātais DNS tuneļa iekšienē ir trešais slānis. Klientiem dotais atrisinātājs pēc savienojuma atbild uz iekšējiem nosaukumiem; tas nevar atrisināt publisko galapunktu, pirms tuneļa nav. Galapunkta atrisināšanas kļūme un iekšējas lietotnes atrisināšanas kļūme notiek dažādos posmos, un to sajaukšana aizved jūs pie nepareizā žurnāla.

Adrešu saime pieder pie tā paša saraksta. IPv4 atbilde neko ne saka par atļauto ceļu IPv6 vai divkāršā steķa galapunktam, tāpēc vienā saimē uzņemts momentuzņēmums nav pierādījums otrai.

Pārbaudiet savienojumu, neko nefiksējot

Sāciet ar profilu tādu, kāds tas eksportēts, un izlasiet, ko tas patiešām prasa:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Pēc tam salīdziniet trīs lietas: profila galapunkta nosaukumu, adresi, ko klients ziņo jaunam mēģinājumam, un to, uz ko nosaukums tagad atrisinās. Nosaukums, kas atrisinās, pierāda tikai to, ka ieraksts atbild; transports un autentifikācija ir atsevišķi, un galapunktam nav jāatbild uz ping. Paša klienta žurnāls ir vienīgais vidējā elementa avots, tāpēc ierakstiet to mēģinājuma laikā, nevis pēc tam.

Adrese, kas atbild šodien, ir pierādījums par šodienu; nosaukums ir tas, ko pakalpojums uztur derīgu. Pierakstiet novērojumu, nosūtiet to galapunkta īpašniekam un atstājiet profilu vērstu uz nosaukumu.

Divus ieradumus atmest: sertifikātu pārbaužu izslēgšanu, lai izietu garām iesprūdušam handshake, un etiķešu krāšanu galapunkta nosaukuma priekšā cerībā, ka viena pielīps. Etiķete atrisinās caur wildcard ierakstu, vai arī problēma ir citur. Ja pareizi konfigurēts profils joprojām neizdodas, nosūtiet precīzu vaicājumu un savienojuma notikumu, nevis garāku resursdatora nosaukumu.

Pirms aizverat: profils joprojām nes eksportēto galapunkta nosaukumu, neviens hosts fails nefiksē adresi, klienta žurnāla remote atbilst pašreizējam atrisinājumam, un ugunsmūra noteikums nosauc galapunktu, nevis adresi. Tas ir arī stāvoklis, kas jānodod nākamajam cilvēkam.