AWS Client VPN végpont DNS: miért vall kudarcot a feloldott IP rögzítése

Múlt héten dig +short egy címet adott az AWS Client VPN-profilja végpontnevéhez, és az alagút csatlakozott. Ezen a héten ugyanaz a profil 'Connecting' állapotban áll a laptopján, miközben egy kolléga érintetlen másolata továbbra is működik. Semmit nem blokkoltak, és a tanúsítvány nem járt le. Valaki lecserélte a végpont gazdagépnevét arra a feloldott címre, és a szolgáltatás már nem válaszol ott. Az exportált név az a rész, amelyet arra építettek, hogy túlélje ezt a változást.

Lehet, hogy a profilban lévő név nem az a név, amelyre a lekérdezés irányul

A Client VPN-ből exportált profilok gyakran tartalmaznak remote-random-hostname. Ha ez a beállítás be van kapcsolva, a kliens egy eldobható címkét épít, ponttal hozzáfűzi a végpont nevéhez, és feloldja az összetett nevet. A végpont zónájában lévő wildcard rekord bármely címkére válaszol, ezért oldódik fel egy kitalált előtag is, és ezért marad láthatatlan a trükk, amikor kézzel próbálja megismételni a lekérdezést.

Tehát amikor beilleszti a végpont nevét egy terminálba, és választ kap, más nevet oldott fel, mint amelyet a kliens csatlakozáskor használ. Ez az eltérés nem a profilban javítandó hiba. A címke szándékosan újragenerálódik: a beállítás megakadályozza, hogy a gyorsítótárak elavult választ tartsanak, és soha nem azonosítja a gépét vagy a munkamenetét.

Találkoztam azzal a kompatibilitási esettel, amikor a kliens teljesen figyelmen kívül hagyja a beállítást. Az AWS dokumentálja a megkerülést: tartsa meg az igazi végpontnevet, és tegyen elé egy véletlen karakterláncot meg egy pontot, névadási mintának tekintve, nem beillesztendő értéknek. Ezt egy régi kliensen alkalmazni észszerű; az előtagos karakterláncot végpontként keménykódolni nem az.

Miért nem maradhat helyes egy elmentett válasz

A Client VPN végpontcímeit az AWS kezeli, és idővel változnak, amit a legjobb gyakorlatok dokumentációja egyenesen kimond. A rögzített válasz egyetlen feloldás pillanatképe. Az ezt keménykódoló profil olyan profillá válik, amely egy üzemen kívül helyezett gazdagépre mutat, amint a szolgáltatás elmozdul, és a hiba ritkán hasonlít DNS-re: kapcsolódási időtúllépést vagy megakadt kézfogást kap, ezért az emberek az útválasztás és a tanúsítványok után rohannak.

Ugyanaz a válasz a /etc/hosts fájlban ugyanazt a lejáratot örökli egy plusz problémával. A hosts bejegyzés túléli az újraindításokat, az újraexportálást és a 'telepítse újra a klienst' javításokat, ezért a hiba minden alkalommal visszatér, amikor a cím elmozdul. Láttam egyet hetekig ártalmatlanul állni, majd minden gépet kikapcsolni, amely hordozta, miközben a friss telepítések normálisan csatlakoztak. Ez a szakadás, az egyik csoport hibázik, a másik rendben van ugyanabban a fiókban, a legolcsóbb nyom, amit kaphat.

A véletlenszerűsítés hatókörét is helyesen határozza meg. Kapcsolódási kísérletenként történik. A kiépült alagút nem oldja fel újra a végpontját, nem vált szervert a munkamenet közepén, és az egyes alkalmazáskérések nem választanak külön-külön új VPN-gazdagépet. Csak a következő kísérlet old fel újra, ezért az egész délután működő munkamenet semmit nem mond a holnap reggelről.

Mit ellenőriz a szolgáltatás, amikor az alagút feláll

A Client VPN megköveteli, hogy a csatlakozott cím megegyezzen a végpont DNS-nevéhez feloldott címmel. Ez az egy követelmény magyaráz több összefüggéstelennek tűnő hibát: egy máshová mutató egyéni DNS-rekordot, egy egyéni frontendet, amely a valódi végpontcímre továbbít, és egy nyers címre átírt profilt. Az AWS az egyéni rekord plusz továbbítás elrendezését hibaként dokumentálja az újabb AWS-kliensekkel. Az ellenőrzés szűk; nem mondja ki, hogy minden alias tilos.

Ez sem általános szabály a VPN-protokollokról. A numerikus remote teljesen érvényes egy szokásos OpenVPN-telepítésben, és sok így működik. A korlát a kezelt elrendezésből jön, nem az alatta lévő protokollból.

Ami a tanúsítvány-ellenőrzés lazítását rossz reflexszé teszi. Ha egy profil címcsere után meghibásodik, a kiszolgáló-ellenőrzés kikapcsolása elmozdítja a hibát ahelyett, hogy helyrehozná a feloldást vagy a címeegyezés követelményét, és olyan klienst hagy hátra, amely bármiben bízni fog. Tartsa meg az exportált CA-t, a kiszolgáló-ellenőrzést és a kölcsönös hitelesítés beállításait pontosan úgy, ahogy érkeztek.

Az engedélylisták, a kimenő forgalom és a privát DNS három külön probléma

A tűzfal-szabály, amelynek engedélyeznie kell egy célállomást, mielőtt a laptop csatlakozik, a külső figyelőről szól. Adja meg a hálózat tulajdonosának a végpontnevet, a szállítást és a beállított portot, majd kérdezze meg, követheti-e az irányításuk a szolgáltatás DNS-viselkedését. Az egyetlen rögzített címet tartó szabály íratlan lejáratú pillanatkép. Ha az irányítás csak változatlan célokat fogad el, a bevezetés előtt zárja be ezt a rést, ahelyett hogy csendben keménykódolna egy választ.

A partnernek, akinek fix forráscímre van szüksége az alagút felállása utáni kérésekhez, más a követelménye: a kimenő forgalom. Hogy egy webhely mit lát, az alkalmazásútvonaltól és az osztott alagút szabályzatától függ, nem attól a címtől, amelyhez a kliens csatlakozott. Az osztott alagút forgalma egyáltalán nem is érintheti az AWS-t.

Az alagúton belüli privát DNS a harmadik réteg. A klienseknek adott feloldó a csatlakozás után belső nevekre válaszol; a nyilvános végpontot nem tudja feloldani, mielőtt az alagút létezik. A végpontfeloldási hiba és a belső alkalmazásfeloldási hiba különböző szakaszokban történik, és összekeverésük a rossz naplóhoz vezet.

A címcsalád ugyanarra a listára tartozik. Az IPv4-válasz semmit nem mond az IPv6-os vagy kettős vermű végpont engedélyezett útvonaláról, ezért az egyik családban készült pillanatkép nem bizonyíték a másikra.

Ellenőrizzen kapcsolatot anélkül, hogy bármit rögzítene

Kezdje az exportált profillal, és olvassa el, mit kér valójában:

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

Ezután hasonlítson össze három dolgot: a profilban lévő végpontnevet, a kliens által egy friss kísérlethez jelentett címet, és azt, hogy a név most mire oldódik fel. A feloldódó név csak azt bizonyítja, hogy a rekord válaszol; a szállítás és a hitelesítés különálló, és a végpontnak nem kell pingre válaszolnia. A középső elemhez egyedül a kliens saját naplója a forrás, ezért a kísérlet alatt rögzítse, nem utána.

A ma válaszoló cím a méről a bizonyíték; a név az, amit a szolgáltatás érvényben tart. Jegyezze fel a megfigyelést, küldje el a végpont tulajdonosának, és hagyja a profilt a névre mutatni.

Két szokást el kell hagyni: a tanúsítvány-ellenőrzések kikapcsolását egy megakadt kézfogás átlépéséhez, és a címkék halmozását a végpontnév elé abban a reményben, hogy az egyik megragad. A címke a wildcard rekordon keresztül oldódik fel, vagy a probléma máshol van. Ha egy helyesen beállított profil továbbra is meghibásodik, a pontos lekérdezést és a kapcsolódási eseményt küldje el, nem hosszabb gazdagépnevet.

Mielőtt lezárja: a profil továbbra is az exportált végpontnevet hordozza, semmilyen hosts fájl nem rögzíti a címet, a kliensnapló remote értéke aktuális feloldásnak felel meg, és a tűzfalszabály a végpontot nevezi meg, nem egy címet. Ez az az állapot is, amelyet át kell adni a következő embernek.