Router nou, același server VPN: mutați intrarea lui publică

Conectați routerul nou, internetul revine, iar clientul VPN de pe telefon indică în continuare o adresă care nu mai răspunde. Pe serverul VPN nu s-a schimbat nimic, pentru că serverul nu s-a mutat niciodată. Routerul era punctul de intrare public, iar înlocuirea lui a înlocuit adresa, regula de redirecționare și poate actualizatorul pentru DNS dinamic în același timp.

Tratați schimbarea ca două predări, nu una, și păstrați o cale locală către interfața de administrare cât timp lucrați.

Notați predarea înainte de a deconecta

Notați prefixul LAN, adresa serverului și modul în care este alocată, ascultătorul și transportul pe care VPN-ul le folosește efectiv, regula de intrare care îl publică și numele pe care clienții l-au salvat. Apoi notați ce mașină actualizează astăzi înregistrarea DNS dinamică: poate fi routerul, serverul însuși sau un agent separat pe alt host. Faceți asta cât timp paginile vechi de administrare încă se încarcă. O captură de ecran a regulii de intrare valorează mai mult decât un număr de port ținut minte.

Adăugați prefixele private la care clienții trebuie să ajungă și modul în care dispozitivele din LAN le trimit răspunsurile înapoi. Ambele se uită ușor, pentru că asistentul de înlocuire vorbește despre acces la internet, nu despre căi de întoarcere. Exportați și configurația veche dacă producătorul acceptă restaurarea ei, acceptând că o copie de siguranță de la un model se importă rar curat în altul.

Păstrați acea notă într-un loc protejat. O copie de siguranță a routerului poate conține date de autentificare pentru legătura WAN. Tratați fișierul exportat ca pe o parolă, nu ca pe o notă despre setări.

Mutați mai întâi adresa, apoi redirecționarea

Dacă routerul nou păstrează același prefix LAN, dați serverului rezervarea pe care o avea sau o alocare statică echivalentă. Dacă prefixul se schimbă, actualizați mai întâi adresa serverului și orice legătură de ascultător care o numește, pentru că o redirecționare către adresa veche va trimite traficul în tăcere nicăieri.

Apoi recreați exact o regulă de intrare pentru transportul pe care îl folosește VPN-ul. Ghidurile producătorilor care descriu redirecționarea către un server local arată mecanismul, nu o rețetă universală, așa că potriviți regula la protocolul și portul real, nu la o listă de pe un blog. O redirecționare pe routerul nou nu poate elimina NAT-ul de nivel de operator care stă deasupra, iar nicio regulă locală nu va face o adresă privată accesibilă din internet dacă furnizorul împarte deja una cu dumneavoastră.

Confirmați că firewall-ul serverului însuși mai permite acel trafic. Verificați dacă între router și internet stă o a doua poartă, pentru că mulți furnizori livrează modem și router combinate. Citiți adresa WAN de pe dispozitivul nou și comparați-o cu adresa pe care o rezolvă clienții. Dacă diferă, redirecționarea dumneavoastră aterizează pe ceva ce nu este marginea.

Decideți cine actualizează numele public

Actualizările punctului final au nevoie de un proprietar și doar de unul. Dacă routerul vechi publica numele, configurați un actualizator acceptat pe înlocuitor și confirmați că înregistrarea s-a schimbat într-adevăr. Dacă serverul îl publica deja, lăsați acea rânduială în pace în loc să adăugați un actualizator concurent care oscilează între două adrese.

Când implementarea publică ambele familii de adrese, citiți atât înregistrarea A, cât și AAAA. Fiecare trebuie să indice un serviciu care ascultă cu adevărat și care este permis prin propria cale de firewall, iar o mapare IPv4 funcțională nu spune nimic despre partea IPv6. Păstrați și verificările de identitate din profilul clientului: o adresă publică schimbată nu este un motiv să acceptați un certificat sau o cheie de partener care nu se potrivește.

Demonstrați schimbarea din exterior

Testați cu o conexiune externă autorizată și o sesiune nouă, nu din interiorul LAN-ului. Un test intern împotriva adresei publice depinde de comportamentul de întoarcere către propria adresă și parcurge o cale diferită de cea a unui client real.

Urmați secvența pe care o urmează un client: rezolvați numele, negociați tunelul, autentificați-vă, apoi executați o operație asupra unei resurse private. Exact acel ultim pas este sărit de oameni și doar el dovedește calea de întoarcere. Dacă autentificarea reușește dar operația privată eșuează, comparați noul prefix LAN, rutele alese de client și calea de răspuns a resursei cu notițele dumneavoastră de predare.

Numai după ce trec toate cele patru etape routerul vechi poate fi retras în siguranță. Deconectați-l, apoi repetați testul extern încă o dată. O înregistrare învechită care încă se rezolvă la adresa veche eșuează deja la prima etapă, iar asta se diagnostichează mai ușor cât timp dispozitivul vechi este încă pe raft.

Păstrați noua mapare lângă notițele de recuperare

Arhivați alocarea finală a serverului, regula de intrare și numele proprietarului actualizării lângă procedura de acces local la router. Următoarea înlocuire ar trebui să înceapă de la acea pagină și nu de la un traceroute.

Dacă tunelul încă eșuează din exterior după toate cele de mai sus, verificați dacă adresa publică raportată de router coincide cu cea pe care o rezolvă clienții. Acea singură comparație separă o problemă de DNS de o problemă de redirecționare și durează mai puțin decât citirea încă unui ghid despre redirecționarea porturilor.