AWS Client VPN muturraren DNSa: zergatik huts egiten duen ebatzitako IPa finkatzeak

Joan den astean dig +short -k helbide bat eman zizun zure AWS Client VPN profileko muturreko izenerako, eta tunela konektatu zen. Aste honetan profil berak 'Connecting' egoeran jarraitzen du zure ordenagailu eramangarrian, lankide baten ukitu gabeko kopiak oraindik funtzionatzen duen bitartean. Ez zen ezer blokeatu eta ziurtagiria ez zen iraungi. Norbaitek muturreko ostalari-izena ebatzitako helbide horrekin ordezkatu zuen, eta zerbitzuak ez du han erantzuten. Esportatutako izena aldaketa horri eusteko eraikitako zatia da.

Zure profileko izena agian ez da kontsultatzen den izena

Client VPNtik esportatutako profilek remote-random-hostname izaten dute normalean. Aukera hori piztuta, bezeroak erabilera bakarreko etiketa bat sortzen du, muturreko izenari puntu batekin lotzen dio eta konbinatutako izena ebazten du. Muturrekoaren eremuko komodin-erregistroak edozein etiketari erantzuten dio, horregatik asmatutako aurrizki bat ere ebazten da eta horregatik trikimailua ikusezin geratzen da kontsulta eskuz erreproduzitzen saiatzean.

Beraz, muturreko izena terminalean itsasten duzunean eta erantzun bat jasotzen duzunean, bezeroak konexioan erabiltzen duen izenaz bestelako bat ebatzi duzu. Desadostasun hori ez da profilean zuzendu beharreko akatsa. Etiketa nahita sortzen da berriro: aukerak cacheek erantzun zaharkitua ez atxikitzea lortzen du, eta ez du inoiz zure makina edo saioa identifikatzen.

Bezeroak aukera erabat ignoratzen duen bateragarritasun-kasua aurkitu dut. AWSek konponbidea dokumentatzen du: mantendu benetako muturreko izena eta jarri aurretik ausazko kate bat eta puntu bat, itsasteko balio bat ez bezala izendapen-eredu gisa tratatuz. Bezero zahar batean aplikatzea zentzuzkoa da; aurrizkidun katea mutur gisa gogor kodetzea ez.

Zergatik ezin den gordetako erantzun bat zuzen jarraitu

Client VPN muturreko helbideak AWSek kudeatzen ditu eta denborarekin aldatzen dira, eta praktika onen dokumentazioak argi esaten du. Harrapatutako erantzun bat ebazpen baten argazki bat da. Hura gogor kodetzen duen profila host zaharkitu batera zuzendutako profil bihurtzen da zerbitzua mugitzen den unean, eta hutsegiteak gutxitan dirudi DNSa: konexio-denbora gainditzea edo blokeatutako handshake bat jasotzen duzu, eta jendea bideratzearen eta ziurtagirien atzetik ibiltzen da.

/etc/hosts-ko erantzun berak iraungitze bera heredatzen du, arazo gehigarri batekin. hosts sarrera batek berrabiarazteak, berresportazioak eta 'instalatu bezeroa berriro' konponketak gainditzen ditu, beraz huts egiteak helbidea mugitzen den bakoitzean itzultzen da. Ikusi dut bat asteetan kalterik gabe egon zela, eta gero hura zeramaten makina guztiak kanpoan utzi zituela instalazio berriak normaltasunez konektatzen ziren bitartean. Banaketa hori, talde bat huts egiten eta beste bat ondo kontu berean, lortuko duzun arrastorik merkeena da.

Mugatu ausazkotzea behar bezala. Konexio-saiakerako gertatzen da. Ezarritako tunel batek ez du bere muturra berriro ebazten, ez du zerbitzariak aldatzen saioaren erdian, eta aplikazioen eskaera indibidualek ez dute bakoitzak VPN ostalari berri bat hautatzen. Hurrengo saiakerak soilik ebazten du berriro, horregatik arratsalde osoan funtzionatzen duen saio batek ez du ezer esaten biharko goizaz.

Zer egiaztatzen duen zerbitzuak tunela altxatzen denean

Client VPNek eskatzen du konektatuta zauden helbidea muturrekoaren DNS izenerako ebatzi den helbide batekin bat etortzea. Baldintza horrek bakarrik azaltzen ditu loturarik gabeak diruditen hainbat hutsegite: beste leku batera seinalatzen duen DNS erregistro pertsonalizatua, muturreko benetako helbidera birbidaltzen duen frontend pertsonalizatua eta helbide gordinean berridatzitako profila. AWSek erregistro pertsonalizatuaren eta birbidaltzearen konbinazioa hutsegite gisa dokumentatzen du azken AWS bezeroekin. Egiaztapena estua da; ez da alias guztiak debekatuta daudela dioen epaia.

Ez da VPN protokoloei buruzko arau orokorra ere. remote zenbakizkoa erabat baliozkoa da OpenVPN ezarpen arrunt batean, eta askok horrela funtzionatzen dute. Murrizketa kudeatutako antolamendutik dator, ez azpian dagoen protokolotik.

Horrek ziurtagirien egiaztapena lasaitzea erreflexu okerra bihurtzen du. Helbide aldaketaren ondoren profilek huts egiten badu, zerbitzariaren egiaztapena desgaitzeak errorea lekuz aldatzen du ebazpena edo helbidearen bat-etortze baldintza konpondu beharrean, eta edozertan fidatuko den bezero bat uzten du. Mantendu esportatutako CA, zerbitzariaren egiaztapena eta elkarrekiko autentifikazio ezarpenak etorri ziren bezala.

Baimen-zerrendak, irteera eta DNS pribatua hiru arazo bereizi dira

Ordenagailu eramangarria konektatu aurretik helmuga bat baimendu behar duen suebakiko araua kanpoko entzuleari buruzkoa da. Eman sarearen jabeari muturreko izena, garraioa eta konfiguratutako ataka, eta gero galdetu ea haien kontrolak zerbitzuaren DNS jokabidea jarraitu dezakeen. Harrapatutako helbide bat mantentzen duen araua idatzi gabeko iraungitze bat duen argazkia da. Kontrolak helmuga aldaezinak soilik onartzen baditu, hutsune hori hedapenaren aurretik konpondu, isilik erantzun bat gogor kodetu beharrean.

Tunela altxatu ondorengo eskaeretarako iturburu-helbide finkoa behar duen bazkideak beste baldintza bat du: irteera. Webgune batek ikusten duena aplikazioaren bidearen eta tunel zatituaren politikaren araberakoa da, ez bezeroa konektatu zen helbidearen araberakoa. Tunel zatituko trafikoak baliteke AWS ukitu ere ez egitea.

Tunelaren barruko DNS pribatua hirugarren geruza da. Bezeroei ematen zaien ebazlea konexioaren ondoren barne-izenei erantzuten die; ezin du muturreko publikoa ebazti tunela existitu aurretik. Muturrekoaren ebazpen-hutsegitea eta barne-aplikazio baten ebazpen-hutsegitea etapa ezberdinetan gertatzen dira, eta biak nahasteak errore-log okerrean.

Helbide-familia zerrenda berean sartzen da. IPv4 erantzun batek ez du ezer esaten IPv6 edo pila bikoitzeko mutur baten baimendutako bideaz, beraz familia batean hartutako argazki bat ez da bestearen froga.

Egiaztatu konexio bat ezer finkatu gabe

Hasi esportatu zen moduan dagoen profiletik eta irakurri zer eskatzen duen:

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

Ondoren alderatu hiru gauza: profilean dagoen muturreko izena, bezeroak saiakera berri baterako jakinarazten duen helbidea eta izena oraintxe zer ebazten duen. Ebazten den izen batek erregistroak erantzuten duela besterik ez du frogatzen; garraioa eta autentifikazioa bereiziak dira, eta muturrak ez du ping-ari erantzun behar. Bezeroaren beraren loga da erdiko elementurako iturri bakarra, beraz harrapatu saiakera bitartean, ez ondoren.

Gaur erantzuten duen helbidea gaurko froga da; izena da zerbitzuak baliozko mantentzen duena. Idatzi behaketa, bidali muturrekoaren jabea denari, eta utzi profila izenera seinalatzen.

Bi ohitura uzteko: ziurtagiri-egiaztapenak desgaitzea blokeatutako handshake bat gainditzeko, eta etiketak muturreko izenaren aurrean pilatzea bat itsatsiko delakoan. Etiketa komodin-erregistroaren bidez ebazten da edo arazoa beste nonbait dago. Behar bezala konfiguratutako profilek oraindik huts egiten badu, bidali kontsulta zehatza eta konexio-gertaera, ez ostalari-izen luzeagoa.

Itxi aurretik: profileak oraindik esportatutako muturreko izena darama, inongo hosts fitxategik ez du helbidea finkatzen, bezeroaren logeko remote uneko ebazpen batekin bat dator eta suebakiko arauak muturra aipatzen du, ez helbide bat. Hori da hurrengo pertsonari eman beharreko egoera ere.