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

Prošli tjedan dig +short vam je dao jednu adresu za naziv završne točke u vašem AWS Client VPN profilu i tunel se povezao. Ovaj tjedan isti profil stoji na 'Connecting' na vašem prijenosniku dok netaknuta kopija kolege još radi. Ništa nije bilo blokirano i certifikat nije istekao. Netko 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 stvara jednokratnu oznaku, spaja je s nazivom završne točke toč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 generira: opcija sprječava da keševi drže zastarjeli odgovor i nikada ne identificira vaše računalo ni sesiju.

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

Zašto spremljeni 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 snimka je 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 'ponovno instaliraj klijenta', pa se kvar vraća svaki put kad se adresa preseli. Gledao sam kako jedan tjednima stoji bezopasno, a zatim onesposobi svako računalo koje ga nosi, dok su se svježe instalacije normalno povezivale. Ta podjela, jedna skupina 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 ponovno svoju završnu točku, ne mijenja poslužitelj usred sesije, a pojedinačni zahtjevi aplikacija ne biraju svaki novi VPN host. Samo sljedeći pokušaj ponovno razrješava, zato sesija koja radi cijelo poslijepodne ne govori ništa o sutrašnjem jutru.

Što usluga provjerava kad 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 dokumentira 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će 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 poslužitelja pomiče grešku umjesto da popravi razrješavanje ili uvjet podudaranja adrese i ostavlja klijenta koji će vjerovati bilo čemu. Držite izvezeni CA, provjeru poslužitelja i postavke uzajamne autentifikacije točno onakvima kakve su došle.

Liste dopuštenja, izlaz i privatni DNS tri su odvojena problema

Pravilo vatrozida koje mora dopustiti odredište prije povezivanja prijenosnika tiče se vanjskog slušatelja. 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 snimka je s neispisanim rokom. Ako kontrola prihvaća 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. Što web lokacija vidi zavisi od rute aplikacije i politike split-tunnel, a ne od adrese na koju se klijent povezao. Split-tunnel promet možda uopće ne dodiruje AWS.

Privatni DNS unutar tunela treći je sloj. Razrješivač 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 događaju se u različitim fazama, a njihovo miješanje vodi vas u pogrešan log.

Adresna obitelj pripada istom popisu. IPv4 odgovor ne govori ništa o dopuštenoj putanji IPv6 ili dual-stack završne točke, pa snimka uzeta u jednoj obitelji nije dokaz za drugu.

Provjerite vezu bez fiksiranja ičega

Počnite od profila kako je izvezen i pročitajte što 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 usporedite tri stvari: naziv završne točke koji profil drži, adresu koju klijent prijavljuje za svjež pokušaj i ono u što 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 tijekom 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 koji 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 konfiguriran profil i dalje ne uspijeva, pošaljite toč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, nijedna hosts datoteka ne fiksira adresu, remote u logu klijenta odgovara trenutnom razrješavanju i pravilo vatrozida imenuje završnu točku, a ne adresu. To je i stanje koje treba predati sljedećoj osobi.