VPN-szerver áthelyezése új nyilvános IP-re: mit ellenőrizzünk először

Egy cím újrakiosztása egy percet vesz igénybe. A következő hét az, ahol az áthelyezés eltörik, és ritkán ott, ahol a szolgáltató konzolja sejteti. Egy új nyilvános IP négy helyen jelenik meg: a socket, amelyen a daemon figyel, a bizalmi horgony, amelyet a kliensek ellenőriznek, minden szabály, amely a régi címet nevezi meg, és a DNS-rekord, amely összeköti őket. Két áthelyezés azonosnak látszik a vezérlőpultról, de teljesen másképp viselkedik: a cím újrakiosztása azon a gépen, amit üzemeltet, vagy egy második endpoint felállítása és a kliensek átvitele rá. Az alábbi ellenőrzések az olcsó hibákat teszik előre, és minden szakasz megmondja, melyik áthelyezésre vonatkozik.

A helyben csere és a párhuzamos átállás különböző feladatok

A helyben csere megtartja a gazdagépet, a kulcsokat, az útválasztási táblát és a felhasználói listát; csak a cím változik. Ezt teszi egy lebegő IP újrakiosztása, és több szolgáltatónál a vendég észre sem veszi, mert a fordítás az instance előtt történik. Az újraépítés vagy a szolgáltatói újrakiosztás durvább: a vendég látja a változást, és minden, ami a régi értéket gyorsítótárazta, ugyanabban a pillanatban értesül róla.

A párhuzamos endpoint egy második gazdagép, amely ugyanazt a munkát végzi. Építse fel, tesztelje egy profillal, és hagyja a régit válaszolni, amíg az új valódi útvonalon bizonyít. Az ár az állapot. Megosztott peer-bejegyzések, visszavonások és naplózás nélkül két hálózata van, amelyek véletlenül ugyanazt a nevet használják.

Keresse meg minden helyet, ahol a régi cím le van írva

Kezdje szöveges átvizsgálással, mert a konfigurációs fájlok a könnyű felét jelentik. Keressen a daemon konfigurációjában, a tűzfal-töredékekben, a monitorozási célokban és a lemezen lévő bármilyen generált klienscsomagban. Vegye bele az IPv6-címet, ha publikál ilyet; az áthelyezés, amely csak az A-rekordot követi, a kettős verem kliensjeit a régi útvonalon hagyja.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

Aztán vizsgálja át a kernelt, mert egy futó rendszer olyan helyeken tartja a címet, amelyeket egyetlen fájl sem említ. Egy statikus forrás-NAT-szabály, egy ipset-bejegyzés, egy bind-cím és egy conntrack-bejegyzés túlélik a konfigurációmódosítást, amely eltávolította őket, és néhányuk újraindítást is túlél, mert egy mentett szabálykészletből tért vissza. Egy szinttel feljebb a szolgáltató biztonsági csoportjai, a terheléselosztó céljai és a monitorozási ellenőrzések egyáltalán nincsenek a fájlrendszerén.

Írja le a leltárt, mielőtt bármit megváltoztat; visszaállítási szkriptként is szolgál.

A hosztnévvel dolgozó kliensek felépülnek; a literális IP-s kliensek elhallgatnak

Ha a kliensek hosztnévvel érik el a szervert, az átállás főleg DNS-probléma, és a tegnap beállított TTL dönti el, mennyire lesz rossz. A feloldók gyorsítótáraznak, a stub feloldók újra gyorsítótáraznak, és sok kliens csak új kapcsolatnál keresi a nevet, így egy létrejött alagút megtartja a kezdőcímét.

Ha az endpoint literális cím, semmi nem oldódik fel újra, és semmi nem naplóz panaszt. A WireGuard eltárolja a feloldott socket-címet: Endpoint = vpn.example.net:51820 IP-vé válik abban a pillanatban, amikor a wg-quick up fut, és az az IP marad, amíg meg nem változtatja. A OpenVPN engedékenyebb: a kapcsolódás idején oldja fel a remote hosztnevet, és a resolv-retry infinite beállítással újra próbálja a DNS-t újracsatlakozáskor. Literális IP esetén mindkettő tovább tárcsáz egy gépet, amely már nem létezik.

Amit az emberek félreértenek, az a tükörkép. Egy kliens, amely már az új címre mutat, miközben a régi figyelő még válaszol, átmegy minden teszten, amit a saját asztalától futtat. Engem is megtévesztett: az új endpoint egy telefonon első próbára feljött, és egy elavult profilú kliens csak akkor került elő, amikor a régi figyelőt sokkal később kikapcsolták.

A bizalom nem költözik a címmel

A WireGuard elválasztja az identitást az elérhetőségtől, ami a címáthelyezést szinte ingyenessé teszi. A peer-eket nyilvános kulcs azonosítja, és az endpoint csak az, ahová a csomagok éppen mennek; egy gazdagép a legutóbbi hitelesített csomag forráscíméből frissíti a peer endpointját. Egy tétlen peernek mégis kell ok arra, hogy az új helyhez beszéljen, és a címet csak akkor tanulja meg, amikor a munkamenete elöregszik, és a handshake újrapróbálkozásai valahol látható helyen kudarcot vallanak. A WireGuard gyors kezdete lefedi az endpoint mezőt.

A TLS-alapú szerverek az ellenkező eset. A tanúsítvány egy névhez kötött, és a címet tárcsázó kliens összehasonlítja a tárcsázottat a tárgy alternatív neveivel. Csatlakozzon IP-vel egy csak DNS SAN-t hordozó tanúsítványhoz, és az ellenőrzés meghiúsul: a kliens által használt név nincs a tanúsítványban. Az IP SAN-nal történő újrakiadás kijavítja azt az egy kapcsolatot, és rosszabbá teszi a következő áthelyezést. Ha hosztnevet hagy a profilban, és a verify-x509-name beállítást a helyén hagyja, szigorú marad az ellenőrzés, miközben a cím alatta változik.

Aztán ellenőrizze, mihez van kötve a daemon; a régi címre rögzített socket csendben meghiúsul. A local 203.0.113.10 beállítással indított OpenVPN-szerver nem hajlandó feljönni, amint az a cím eltűnik, míg a 0.0.0.0 címen figyelő ingyen követi a változást. A NAT ugyanígy oszlik meg: a MASQUERADE azt követi, amilyen címe most a gépnek van, a statikus SNAT --to-source 203.0.113.10 pedig tovább ír át egy olyan címre, amely már nem az öné, így a visszatérő forgalom eltűnik. Ha az új cím más upstream átjáróval jön, ellenőrizze a rp_filter beállítást: a fordított útvonal szűrése eldobja a visszatérő forgalmat, amely olyan interfészen érkezik, amelyet a kernel nem várt.

Az átállás sorrendje és a bizonyíték, hogy működött

Csökkentse a TTL-t egy nappal előbb, állítsa fel az új figyelőt, és bizonyítsa egy olyan profillal, amely csak Önnél van. Az ugyanazon hálózaton belülről végzett teszt szinte semmit nem bizonyít, ezért használjon mobilhálózaton lévő telefont, és teszteljen valamit, amit az alagútnak szállítania kell, ne az endpoint pingjét.

Figyelje mindkét címet az ablak alatt. Az wg show all latest-handshakes az új gazdagépen, vagy az OpenVPN állapotfájlja megmondja, hány peer költözött valóban. Amikor az új endpointon megvannak a várt peerek, a régin pedig csak lemaradók, vonja ki a régi figyelőt, távolítsa el az elavult NAT-szabályt, és vegye ki a címet a szolgáltató tűzfalából. A régi figyelő eltávolítása az a lépés, amely kimarad, és ez zárja be azt a rést, ahol egy elavult profil még eléri a régi hálózatot.

Rögzítse írásban a visszaállítási triggert a kezdés előtt: ha az új endpointnak a megbeszélt ablak után nincs handshakeje egyetlen valódi klienstől sem, állítsa vissza a régi címet, és hagyja abba a profilok terjesztését. Utána futtassa újra az átvizsgálást, és erősítse meg, hogy egyetlen figyelő sem kötődik már kivont címhez. Két dolog kerül át a következő áthelyezésbe: egy hosztnév a kliensprofilban, hogy a következő változás DNS-szerkesztés legyen, és a szerver helyreállítási jegyzetei mellett tárolt leltár.