Naujas maršrutizatorius, tas pats VPN serveris: perkelkite jo viešąjį įėjimą
VPN serveris lieka LAN tinkle, todėl maršrutizatoriaus keitimas yra du perdavimai: kelias iki jo ir viešasis įėjimas, kurį klientai išsaugojo. Perkelkite abu, tada patikrinkite iš išorės.
Prijungiate naują maršrutizatorių, internetas grįžta, o telefone esantis VPN klientas vis dar rodo į adresą, kuris nebeatsako. VPN serveryje niekas nepasikeitė, nes serveris niekada nejudėjo. Maršrutizatorius buvo viešasis įėjimo taškas, o jį pakeitus pakeistas adresas, peradresavimo taisyklė ir galbūt dinaminio DNS atnaujintuvas tuo pačiu metu.
Traktuokite keitimą kaip du perdavimus, o ne vieną, ir darbo metu išsaugokite vietinį kelią į administravimo sąsają.
Užsirašykite perdavimą prieš atjungdami
Užrašykite LAN prefiksą, serverio adresą ir jo priskyrimo būdą, klausytuvą ir transportą, kurį VPN iš tikrųjų naudoja, įeinančią taisyklę, kuri jį paskelbia, ir vardą, kurį išsaugojo klientai. Tada pažymėkite, kuri mašina šiandien atnaujina dinaminio DNS įrašą: tai gali būti maršrutizatorius, pats serveris arba atskiras agentas kitame hoste. Darykite tai, kol seni administravimo puslapiai dar kraunasi. Įeinančios taisyklės ekrano kopija verta daugiau nei prisimintas prievado numeris.
Pridėkite privačius prefiksus, kuriuos klientai turi pasiekti, ir kaip LAN įrenginiai siunčia atsakymus atgal jiems. Abu lengvai pamirštami, nes keitimo vedlys kalba apie interneto prieigą, o ne apie grįžimo kelius. Taip pat eksportuokite seną konfigūraciją, jei gamintojas palaiko jos atkūrimą, priimdami, kad vieno modelio atsarginė kopija retai importuojama švariai į kitą.
Saugokite tą įrašą apsaugotoje vietoje. Maršrutizatoriaus atsarginė kopija gali turėti WAN linijos prisijungimo duomenis. Elkitės su eksporto failu kaip su slaptažodžiu, o ne kaip su nustatymų pastaba.
Pirmiausia perkelkite adresą, tada peradresavimą
Jei naujasis maršrutizatorius išlaiko tą patį LAN prefiksą, duokite serveriui ankstesnę rezervaciją arba lygiavertį statinį priskyrimą. Jei prefiksas keičiasi, pirmiausia atnaujinkite serverio adresą ir bet kokį jį įvardijantį klausytuvo susiejimą, nes peradresavimas į seną adresą tyliai siųs srautą niekur.
Tada sukurkite tiksliai vieną įeinančią taisyklę transportui, kurį naudoja VPN. Gamintojų vadovai, aprašantys peradresavimą į vietinį serverį, rodo mechanizmą, o ne universalų receptą, todėl pritaikykite taisyklę savo tikram protokolui ir prievadui, o ne sąrašui iš tinklaraščio. Peradresavimas naujajame maršrutizatoriuje negali pašalinti veikėjo lygio NAT, esančio virš jo, ir jokia vietinė taisyklė nepadarys privataus adreso pasiekiamo iš interneto, jei teikėjas jau dalijasi vienu su jumis.
Patvirtinkite, kad paties serverio užkarda vis dar leidžia tą srautą. Patikrinkite, ar tarp maršrutizatoriaus ir interneto nėra antrosios šliuzo, nes daugelis teikėjų duoda kombinuotą modemą ir maršrutizatorių. Perskaitykite WAN adresą naujajame įrenginyje ir palyginkite jį su adresu, kurį išsprendžia klientai. Jei jie skiriasi, jūsų peradresavimas nusileidžia ant kažko, kas nėra kraštas.
Nuspręskite, kas atnaujina viešąjį vardą
Galutinio taško atnaujinimams reikia vieno savininko ir tik vieno. Jei senasis maršrutizatorius skelbė vardą, sukonfigūruokite palaikomą atnaujintuvą pakaitaluose ir patvirtinkite, kad įrašas tikrai pasikeitė. Jei serveris jį jau skelbė, palikite tą tvarką ramybėje, o ne pridėkite konkuruojantį atnaujintuvą, kuris svyruoja tarp dviejų adresų.
Kai diegimas skelbia abi adresų šeimas, skaitykite ir A, ir AAAA įrašą. Kiekvienas turi rodyti į paslaugą, kuri tikrai klausosi ir yra leidžiama per savo užkardos kelią, o veikiantis IPv4 atitikimas nieko nesako apie IPv6 pusę. Taip pat išsaugokite tapatybės patikras kliento profilyje: pakeistas viešasis adresas nėra priežastis priimti sertifikatą ar partnerio raktą, kuris neatitinka.
Įrodykite keitimą iš išorės
Bandykite su leidžiamu išoriniu ryšiu ir nauja sesija, o ne iš LAN vidaus. Vidinis bandymas prieš viešąjį adresą priklauso nuo grįžimo į savo adresą elgsenos ir eina kitu keliu nei tikras klientas.
Sekite tvarką, kurios laikosi klientas: išspręskite vardą, derėkitės dėl tunelio, autentifikuokitės, tada atlikite vieną operaciją su privačiu ištekliu. Būtent šį paskutinį žingsnį žmonės praleidžia, ir tik jis įrodo grįžimo kelią. Jei prisijungimas pavyksta, bet privati operacija nepavyksta, palyginkite naują LAN prefiksą, kliento pasirinktus maršrutus ir ištekliaus atsakymo kelią su savo perdavimo pastabomis.
Tik kai praeina visi keturi žingsniai, senąjį maršrutizatorių saugu išleisti iš eksploatacijos. Atjunkite jį, tada dar kartą pakartokite išorinį bandymą. Pasenęs įrašas, kuris vis dar sprendžiamas į seną adresą, nepavyksta jau pirmame žingsnyje, ir tai lengviau diagnozuoti, kol senasis įrenginys dar lentynoje.
Laikykite naują atitikimą su savo atkūrimo pastabomis
Archyvuokite galutinį serverio priskyrimą, įeinančią taisyklę ir atnaujinimo savininko vardą šalia vietinės prieigos prie maršrutizatoriaus procedūros. Kitas keitimas turėtų prasidėti nuo to puslapio, o ne nuo traceroute.
Jei tunelis vis dar nepavyksta iš išorės po viso to, kas išdėstyta aukščiau, patikrinkite, ar viešasis adresas, kurį praneša maršrutizatorius, sutampa su tuo, kurį išsprendžia klientai. Tas vienas palyginimas atskiria DNS problemą nuo peradresavimo problemos, ir tai užima mažiau laiko nei dar vieno prievadų peradresavimo vadovo skaitymas.