DNS završne točke AWS Client VPN: zašto fiksiranje razriješene IP adrese ne radi

Prošle sedmice dig +short vam je dao jednu adresu za naziv završne točke u vašem AWS Client VPN profilu i tunel se povezao. Ove sedmice isti profil stoji na 'Connecting' na vašem laptopu dok netaknuta kopija kolege još radi. Ništa nije bilo blokirano i certifikat nije istekao. Neko je zamijenio ime hosta završne točke tom razriješenom adresom i usluga više ne odgovara tamo. Izvezeni naziv je dio napravljen da preživi tu promjenu.

Naziv u vašem profilu možda nije naziv koji se upituje

Profili izvezeni iz Client VPN-a obično nose remote-random-hostname. Kad je ta opcija uključena, klijent pravi jednokratnu oznaku, spaja je s nazivom završne točke tačkom i razrješava spojeni naziv. Wildcard zapis u zoni završne točke odgovara na svaku oznaku, zato izmišljeni prefiks i dalje radi i zato taj trik ostaje nevidljiv kad upit pokušate ponoviti ručno.

Zato, kad zalijepite naziv završne točke u terminal i dobijete odgovor, razriješili ste drugi naziv od onog koji klijent koristi pri povezivanju. To neslaganje nije greška koju treba ispravljati u profilu. Oznaka se namjerno iznova generiše: opcija sprječava da keševi drže zastarjeli odgovor i nikada ne identifikuje vašu mašinu ni sesiju.

Naišao sam na slučaj kompatibilnosti gdje klijent opciju potpuno ignorira. AWS dokumentuje zaobilazno rješenje: zadržite pravi naziv završne točke i ispred dodajte slučajni niz plus tačku, tretirajući to kao obrazac imenovanja, a ne kao vrijednost za lijepljenje. Primijeniti to na stari klijent je razumno; hardkodirati prefiksirani niz kao završnu točku nije.

Zašto sačuvani odgovor ne može ostati ispravan

Adresama završne točke Client VPN-a upravlja AWS i mijenjaju se s vremenom, što dokumentacija o najboljim praksama jasno kaže. Zabilježen odgovor je snimak jednog razrješavanja. Profil koji ga hardkodira postaje profil usmjeren na isključeni host čim se usluga preseli, a kvar rijetko izgleda kao DNS: dobijete istek vremena povezivanja ili zastali handshake, pa ljudi jure routing i certifikate.

Isti odgovor u /etc/hosts nasljeđuje isti rok uz dodatni problem. Zapis u hosts preživljava restartove, ponovne izvoze i popravke 'ponovo instaliraj klijenta', pa se kvar vraća svaki put kad se adresa preseli. Gledao sam kako jedan sedmicama stoji bezopasno, a zatim onesposobi svaku mašinu koja ga nosi, dok su se svježe instalacije normalno povezivale. Ta podjela, jedna grupa ne uspijeva a druga je dobra na istom računu, najjeftiniji je trag koji ćete dobiti.

Ispravno ograničite i randomizaciju. Ona se događa po pokušaju povezivanja. Uspostavljeni tunel ne razrješava ponovo svoju završnu točku, ne mijenja server usred sesije, a pojedinačni zahtjevi aplikacija ne biraju svaki novi VPN host. Samo sljedeći pokušaj ponovo razrješava, zato sesija koja radi cijelo poslijepodne ne govori ništa o sutrašnjem jutru.

Šta usluga provjerava kada se tunel podigne

Client VPN zahtijeva da adresa na koju ste povezani odgovara adresi razriješenoj za DNS naziv završne točke. Taj jedan uvjet objašnjava nekoliko kvarova koji izgledaju nepovezano: prilagođeni DNS zapis koji pokazuje negdje drugdje, prilagođeni frontend koji prosljeđuje na pravu adresu završne točke i profil prepisan na sirovu adresu. AWS dokumentuje kombinaciju prilagođenog zapisa i prosljeđivanja kao kvar s novijim AWS klijentima. Provjera je uska; to nije presuda da je svaki alias zabranjen.

To nije ni opšte pravilo o VPN protokolima. Numerički remote potpuno je valjan u običnom OpenVPN postavljanju i mnogi tako rade. Ograničenje dolazi od upravljanog aranžmana, ne od protokola ispod njega.

Zbog toga je popuštanje provjere certifikata pogrešan refleks. Ako profil ne uspije nakon zamjene adrese, isključivanje provjere servera pomjera grešku umjesto da popravi razrješavanje ili uvjet podudaranja adrese i ostavlja klijenta koji će vjerovati bilo čemu. Držite izvezeni CA, provjeru servera i postavke uzajamne autentifikacije tačno onakvima kakve su došle.

Liste dozvola, izlaz i privatni DNS tri su odvojena problema

Pravilo firewall-a koje mora dopustiti odredište prije povezivanja laptopa tiče se vanjskog listenera. Dajte vlasniku mreže naziv završne točke, transport i konfigurirani port, pa pitajte može li njihova kontrola slijediti DNS ponašanje usluge. Pravilo koje drži jednu zabilježenu adresu snimak je s neispisanim rokom. Ako kontrola prihvata samo nepromjenjiva odredišta, riješite taj jaz prije uvođenja umjesto da tiho hardkodirate odgovor.

Partneru koji treba fiksnu izvornu adresu za zahtjeve nakon podizanja tunela treba nešto drugo: izlaz. Šta web lokacija vidi zavisi od rute aplikacije i politike split-tunnel, a ne od adrese na koju se klijent povezao. Split-tunnel saobraćaj možda uopšte ne dodiruje AWS.

Privatni DNS unutar tunela treći je sloj. Resolver koji se daje klijentima odgovara na interne nazive nakon povezivanja; ne može razriješiti javnu završnu točku prije nego tunel postoji. Kvar razrješavanja završne točke i kvar razrješavanja interne aplikacije dešavaju se u različitim fazama, a njihovo miješanje vodi vas u pogrešan log.

Adresna porodica pripada istom spisku. IPv4 odgovor ne govori ništa o dopuštenoj putanji IPv6 ili dual-stack završne točke, pa snimak uzet u jednoj porodici nije dokaz za drugu.

Provjerite vezu bez fiksiranja ičega

Počnite od profila kako je izvezen i pročitajte šta zapravo traži:

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

Zatim uporedite tri stvari: naziv završne točke koji profil drži, adresu koju klijent prijavljuje za svjež pokušaj i ono u šta se naziv sada razrješava. Naziv koji se razrješava dokazuje samo da zapis odgovara; transport i autentifikacija su odvojeni i završna točka ne mora odgovoriti na ping. Vlastiti log klijenta jedini je izvor za srednju stavku, pa ga zabilježite tokom pokušaja, a ne poslije.

Adresa koja odgovara danas dokaz je o danas; naziv je ono što usluga održava važećim. Zabilježite zapažanje, pošaljite ga onome ko posjeduje završnu točku i ostavite profil usmjeren na naziv.

Dvije navike treba napustiti: isključivanje provjera certifikata da bi se prošao zastali handshake i gomilanje oznaka ispred naziva završne točke u nadi da će se jedna zadržati. Oznaka se razrješava kroz wildcard zapis ili je problem negdje drugdje. Ako ispravno konfigurisan profil i dalje ne uspijeva, pošaljite tačan upit i događaj povezivanja, a ne duže ime hosta.

Prije nego što to zatvorite: profil još nosi izvezeni naziv završne točke, nijedan hosts fajl ne fiksira adresu, remote u logu klijenta odgovara trenutnom razrješavanju i firewall pravilo imenuje završnu točku, a ne adresu. To je i stanje koje treba predati sljedećoj osobi.