DNS končne točke AWS Client VPN: zakaj pripenjanje razrešenega IP ne deluje

Prejšnji teden vam je dig +short dal en naslov za ime končne točke v vašem profilu AWS Client VPN in tunel se je povezal. Ta teden isti profil stoji na 'Connecting' na vašem prenosniku, medtem ko nedotaknjena kopija kolega še deluje. Nič ni bilo blokirano in potrdilo ni poteklo. Nekdo je zamenjal ime gostitelja končne točke s tem razrešenim naslovom in storitev tam ne odgovarja več. Izvoženo ime je del, zgrajen zato, da preživi to spremembo.

Ime v vašem profilu morda ni ime, po katerem se sprašuje

Profili, izvoženi iz Client VPN, običajno vsebujejo remote-random-hostname. Ko je ta možnost vključena, odjemalec zgradi enkratno oznako, jo s piko pripne k imenu končne točke in razreši sestavljeno ime. Nadomestni zapis v coni končne točke odgovori na katero koli oznako, zato se izmišljena predpona še vedno razreši in zato trik ostane neviden, ko poskušate poizvedbo ponoviti ročno.

Ko torej prilepite ime končne točke v terminal in dobite odgovor, ste razrešili drugo ime od tistega, ki ga odjemalec uporablja ob povezavi. To neskladje ni napaka, ki bi jo bilo treba popraviti v profilu. Oznaka se namenoma ustvari znova: možnost preprečuje, da bi predpomnilniki hranili zastarel odgovor, in nikoli ne identificira vašega računalnika ali seje.

Naletel sem na primer združljivosti, ko odjemalec možnost povsem ignorira. AWS dokumentira obhod: obdržite pravo ime končne točke in pred njim dodajte naključni niz ter piko, pri čemer to obravnavajte kot vzorec poimenovanja in ne kot vrednost za lepljenje. Uporabiti to na starem odjemalcu je smiselno; trdo kodirati predpono kot končno točko ni.

Zakaj shranjen odgovor ne more ostati pravilen

Naslove končnih točk Client VPN upravlja AWS in se s časom spreminjajo, kar dokumentacija najboljših praks pove naravnost. Zajet odgovor je posnetek ene razrešitve. Profil, ki ga trdo kodira, postane profil, usmerjen v upokojeni gostitelj, takoj ko se storitev premakne, in napaka redko izgleda kot DNS: dobite časovno omejitev povezave ali zataknjen handshake, zato ljudje lovijo usmerjanje in potrdila.

Isti odgovor v /etc/hosts podeduje isti rok s še eno težavo. Vnos hosts preživi ponovne zagone, nove izvoze in popravke 'znova namesti odjemalca', zato se napaka vrne vsakič, ko se naslov premakne. Videl sem enega, kako je tedne ležal neškodljiv in nato izklopil vsak stroj, ki ga je nosil, medtem ko so se sveže namestitve povezovale normalno. Ta razcep, ena skupina odpove, druga pa je v redu na istem računu, je najcenejša sled, ki jo boste dobili.

Pravilno omejite obseg naključnosti. Zgodi se pri vsakem poskusu povezave. Vzpostavljen tunel ne razreši znova svoje končne točke, ne zamenja strežnika sredi seje in posamezne zahteve aplikacij ne izberejo vsaka novega gostitelja VPN. Znova razreši le naslednji poskus, zato seja, ki deluje celo popoldne, ne pove ničesar o jutrišnjem jutru.

Kaj storitev preveri, ko se tunel dvigne

Client VPN zahteva, da se naslov, s katerim ste povezani, ujema z naslovom, razrešenim za DNS ime končne točke. Ta ena zahteva pojasni več napak, ki se zdijo nepovezane: lasten zapis DNS, ki kaže drugam, lasten frontend, ki posreduje na pravi naslov končne točke, in profil, prepisan na surov naslov. AWS dokumentira kombinacijo lastnega zapisa in posredovanja kot napako z novejšimi odjemalci AWS. Preverjanje je ozko; ni razsodba, da je vsak alias prepovedan.

To tudi ni splošno pravilo o protokolih VPN. Številski remote je povsem veljaven v običajni namestitvi OpenVPN in mnogi delujejo tako. Omejitev izhaja iz upravljane ureditve, ne iz protokola pod njo.

Zato je popuščanje preverjanja potrdil napačen refleks. Če profil po zamenjavi naslova odpove, izklop preverjanja strežnika premakne napako, namesto da bi popravil razrešitev ali zahtevo po ujemanju naslova, in pusti odjemalca, ki bo zaupal čemur koli. Obdržite izvoženi CA, preverjanje strežnika in nastavitve medsebojnega preverjanja točno takšne, kot so prišle.

Seznami dovoljenih, izhod in zasebni DNS so tri ločene težave

Pravilo požarnega zidu, ki mora dovoliti cilj preden se prenosnik poveže, zadeva zunanjega poslušalca. Lastniku omrežja dajte ime končne točke, transport in konfigurirana vrata, nato pa vprašajte, ali lahko njihov nadzor sledi vedenju DNS storitve. Pravilo, ki zadrži en zajet naslov, je posnetek z nezapisano veljavnostjo. Če nadzor sprejema le nespremenljive cilje, to vrzel rešite pred uvedbo, namesto da bi tiho trdo kodirali odgovor.

Partner, ki potrebuje fiksni izvorni naslov za zahteve po dvigu tunela, ima drugo zahtevo: izhod. Kar vidi spletno mesto, je odvisno od poti aplikacije in politike razdeljenega tunela, ne od naslova, s katerim se je odjemalec povezal. Promet v razdeljenem tunelu se morda sploh ne dotakne AWS.

Zasebni DNS znotraj tunela je tretja plast. Razreševalnik, ki ga dobijo odjemalci, po povezavi odgovori na notranja imena; javne končne točke ne more razrešiti, preden tunel obstaja. Napaka pri razrešitvi končne točke in napaka pri razrešitvi notranje aplikacije se zgodita v različnih fazah, njuno mešanje pa vas pošlje v napačen dnevnik.

Naslovna družina spada na isti seznam. Odgovor IPv4 ne pove ničesar o dovoljeni poti končne točke IPv6 ali z dvojnim skladom, zato posnetek, narejen v eni družini, ni dokaz za drugo.

Preverite povezavo, ne da bi karkoli pripeli

Začnite s profilom, kot je bil izvožen, in preberite, kaj v resnici zahteva:

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

Nato primerjajte tri stvari: ime končne točke, ki ga ima profil, naslov, ki ga odjemalec sporoči za nov poskus, in v kaj se ime razreši zdaj. Ime, ki se razreši, dokazuje samo, da zapis odgovarja; transport in preverjanje sta ločena, končni točki pa ni treba odgovoriti na ping. Lasten dnevnik odjemalca je edini vir za srednjo postavko, zato ga zajemite med poskusom in ne po njem.

Naslov, ki danes odgovarja, je dokaz o današnjem dnevu; ime je tisto, kar storitev ohranja veljavno. Zapišite opažanje, pošljite ga lastniku končne točke in pustite profil usmerjen na ime.

Dve navadi, ki ju opustite: izklapljanje preverjanja potrdil, da bi prešli zataknjen handshake, in kopičenje oznak pred imenom končne točke v upanju, da se ena prime. Oznaka se razreši prek nadomestnega zapisa ali pa je težava drugje. Če pravilno nastavljen profil še vedno odpove, pošljite natančno poizvedbo in dogodek povezave, ne daljšega imena gostitelja.

Preden zaprete: profil še vedno nosi izvoženo ime končne točke, nobena datoteka hosts ne fiksira naslova, remote v dnevniku odjemalca ustreza trenutni razrešitvi in pravilo požarnega zidu imenuje končno točko, ne naslova. To je tudi stanje, ki ga predate naslednji osebi.