A VPN költözött: miért tárcsázza az OpenVPN-klienst még mindig a régi IP-t

A szolgáltató megváltoztatta a nyilvános címét, Ön frissítette a dinamikus DNS-rekordot, és az ügyfél még mindig nem tud csatlakozni. Kívülről úgy tűnik, mintha a rekord nem terjedt volna el. Legtöbbször a rekord rendben van, és az ügyfél azt a címet tárcsázza, amelyet a költözés előtt oldott fel, mert a futó alagút és a mentett profil mindegyikének megvan a maga elképzelése arról, hol lakik a szerver. Három rétegnek kell egyetértenie, és ezek eltérő ütemterv szerint frissülnek.

Azt nézze, mit tárcsáz a profil, ne azt, mit mond a DNS

Nyissa meg a ténylegesen használt kapcsolatot, és olvassa el a remote sort. Az ott lévő numerikus cím soha nem követi a gazdanév frissítését, bármilyen helyes is lesz a rekord.

Ezután ellenőrizze, hogy az általunk szerkesztett profil az-e, amelyet az ügyfél betöltött. Az importált profilok gyakoriak: egy rendszergazda hónapokkal korábban másolatot készíthetett, és megtartotta a saját verzióját, így a letöltési mappában lévő fájl és az alkalmazásban lévő bejegyzés eltérhet. Hasonlítsa össze a végpontot az ügyfél saját kapcsolati adataiban, mielőtt egyáltalán a DNS-t hibakeresné.

Két fájl, egy végpont — itt ez a szokásos lelet.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Olvassa el az ügyfél következő kapcsolódási kísérletét

Indítsa újra a kapcsolatot részletes naplózással, és olvassa el azt a sort, amely megnevezi a címet, amellyel kapcsolatba lép. Az az érték számít, nem az, amelyet a böngészője feloldott.

A feloldó gyorsítótára még őrizheti az előző választ, és egyes hálózatok tovább őrzik, mint amennyit a rekord TTL-je kér. Azt a feloldót kérdezze, amelyet az ügyfél ténylegesen használ, ne egy nyilvánosat, amelyet máshonnan tesztelt.

Ha a napló az új címet mutatja, és a kapcsolat még mindig nem jön létre, a probléma továbbmozdult: a csomag valahová megy, és senki sem válaszol. Ez hallgató, tűzfal vagy porttovábbítás kérdése, és a kiszolgáló oldalán van, nem az ügyfél feloldási útvonalában. Tartsa külön ezt a két hibát, mert egy elérhetetlen hallgatót DNS-problémaként kezelve kétszer járja végig ugyanazt a hurkot.

Tudja, melyik újraindítást végzi

Nem minden újraindítás őrzi meg ugyanazt az állapotot, ezért a címváltozás eltérően viselkedhet attól függően, hogyan ciklizálják a folyamatot. A jelzés által kiváltott lágy újraindítás többet őriz meg az előző munkamenet kontextusából, míg a teljes leállítás és indítás újra a konfigurációból kezd. Ha azt teszteli, hogy az ügyfél újra felold-e, a konfigurációból induló útra van szüksége.

A tartóssági beállítások is számítanak, mert arra szolgálnak, hogy megtartsák azt, amit hitelesítettek, nem arra, hogy új címek után fussanak.

A legtisztább teszt egy friss indítás a szándékolt profilból, majd pillantás a végpontot megnevező naplósorra. Amit egy részben megőrzött munkamenetből tanul, az arról a munkamenetről szóló állítás.

A négy lehetőség és külön feladataik

A gazdanévvel megadott remote az a beállítás, amely egyáltalán lehetővé teszi az újrafeloldást; a szó szerinti cím azon a soron kizárja. A resolv-retry szabályozza, mi történik sikertelen kereséskor, és a 2.6 már alapértelmezésben végtelenre állítja. Hozzáadása tehát nem változtat semmit, és soha nem ütemez időszakos ellenőrzést más válaszért. Aki azt mondja, hogy új címeket kutat, az összekeverte a helyreállítást a frissességgel.

A persist-remote-ip a folytonosságról szól, nem a frissességről: újrahasználja azt a végpontot, amely utoljára hitelesített, az általa támogatott lágy újraindításokon át. Amíg költözést tesztel, ez az ellenkezője annak, amit szeretne. Kapcsolja ki a teszthez, ha a buildje engedélyezi, majd állítsa vissza, amint az új végpont bizonyított. Bekapcsolva hagyva egy sikeres újracsatlakozás semmit sem mondhat a DNS-ről.

A float elfogad egy hitelesített partnert, akinek a címe a munkamenet közben megváltozott, és csak olyan elrendezésekben, amelyek támogatják. Nem frissíti a DNS-t, és nem követi magától a szolgáltatóváltást. Tekintse ellenállóképességi funkciónak a barangoló partnereknél, nem dinamikus címmechanizmusnak a kiszolgálóknál.

Erősítse meg az új végpontot, mielőtt az ügyfelet hibáztatná

A hálózatán kívülről ellenőrizze, hogy az új címen van-e hallgató a beállított porton, és a szolgáltató továbbítása rá mutat-e. Egy helyes A-rekord nyitott port nélküli gépre pontosan azt a tünetet kelti, amelyet az emberek a gyorsítótárazásnak tulajdonítanak.

Ezután csatlakozzon újra, és ellenőrizzen két dolgot: az ügyfél a várt kiszolgálói tanúsítvány ellen hitelesített, és a munkamenet eléri a szándékolt erőforrást. A címváltozás nem csökkenti az identitáskövetelményeket, és a rossz végpontra sikeresen csatlakozó kapcsolat rosszabb, mint a sikertelen. Az OpenVPN 2.6 kézikönyve mind a négy lehetőséget saját hatókörével együtt listázza, és ez az az ellenőrzőlista, amelyet a profil mellett érdemes tartani.

Tartson fenn egy sávon kívüli utat a kiszolgálóhoz, mielőtt újraindítja az alagutat, amely a rendszergazdai hozzáférését hordozza. Ez az egyetlen óvintézkedés megakadályozza a forgatókönyv által okozott esetek többségét.