Новы маршрутызатар, той жа VPN-сервер: перанясіце яго публічны ўваход
VPN-сервер застаецца ў LAN, таму замена маршрутызатара — гэта дзве перадачы: шлях да яго і публічны ўваход, які захавалі кліенты. Перанясіце абодва, потым праверце звонку.
Вы падключаеце новы маршрутызатар, інтэрнэт вяртаецца, а VPN-кліент на тэлефоне ўсё яшчэ паказвае на адрас, які больш не адказвае. На VPN-серверы нічога не змянілася, бо сервер нікуды не пераязджаў. Маршрутызатар быў пунктам публічнага ўваходу, і яго замена адначасова замяніла адрас, правіла перанакіравання і, магчыма, абнаўляльнік дынамічнага DNS.
Разглядайце замену як дзве перадачы, а не адну, і трымайце лакальны шлях у інтэрфейс адміністравання, пакуль працуеце.
Запішыце перадачу да таго, як адключыць
Запішыце прэфікс LAN, адрас сервера і тое, як ён прызначаецца, слухач і транспарт, якія VPN фактычна выкарыстоўвае, правіла ўваходу, якое яго публікуе, і імя, якое захавалі кліенты. Затым адзначце, якая машына сёння абнаўляе запіс дынамічнага DNS: гэта можа быць маршрутызатар, сам сервер або асобны агент на іншым хасце. Рабіце гэта, пакуль старыя старонкі адміністравання яшчэ загружаюцца. Здымак экрана правіла ўваходу лепш за запомнены нумар порта.
Дадайце прыватныя прэфіксы, да якіх павінны дабірацца кліенты, і тое, як прылады ў LAN адпраўляюць ім адказы назад. І тое, і другое лёгка забыць, бо майстар замены гаворыць пра доступ у інтэрнэт, а не пра зваротныя шляхі. Таксама экспартуйце старую канфігурацыю, калі вытворца падтрымлівае яе аднаўленне, прымаючы, што рэзервовая копія адной мадэлі рэдка імпартуецца чыста ў іншую.
Трымайце гэты запіс у абароненым месцы. Рэзервовая копія маршрутызатара можа змяшчаць уліковыя даныя для канала WAN. Стаўцеся да экспартаванага файла як да пароля, а не як да нататкі пра налады.
Спачатку перанясіце адрас, потым перанакіраванне
Калі новы маршрутызатар захоўвае той жа прэфікс LAN, дайце серверу рэзерваванне, якое ён меў, або раўназначнае статычнае прызначэнне. Калі прэфікс змяняецца, спачатку абнавіце адрас сервера і любое прывязванне слухача, якое яго называе, бо перанакіраванне, накіраванае на стары адрас, будзе моўчкі адпраўляць трафік у нікуды.
Затым стварыце роўна адно правіла ўваходу для транспарту, які выкарыстоўвае VPN. Кіраўніцтвы вытворцаў, якія апісваюць перанакіраванне на лакальны сервер, паказваюць механізм, а не ўніверсальны рэцэпт, таму суадносьце правіла з вашым рэальным пратаколам і портам, а не са спісам з блога. Перанакіраванне на новым маршрутызатары не можа прыбраць NAT аператарскага ўзроўню, які стаіць вышэй за яго, і ніякае лакальнае правіла не зробіць прыватны адрас дасяжным з інтэрнэту, калі пастаўшчык ужо дзеліць адзін з вамі.
Пераканайцеся, што ўласны фаервол сервера ўсё яшчэ дазваляе гэты трафік. Праверце, ці не стаіць паміж маршрутызатарам і інтэрнэтам другая брама, бо шмат пастаўшчыкоў выдаюць сумяшчаны мадэм і маршрутызатар. Прачытайце адрас WAN на новай прыладзе і параўнайце яго з адрасам, які развязваюць кліенты. Калі яны розныя, ваша перанакіраванне прызямляецца на нешта, што не з'яўляецца краем.
Вырашыце, хто абнаўляе публічнае імя
Абнаўленні канчатковага пункта патрабуюць аднаго ўладальніка, і толькі аднаго. Калі імя публікаваў стары маршрутызатар, наладзьце падтрымліваемы абнаўляльнік на замене і пацвердзіце, што запіс сапраўды змяніўся. Калі сервер ужо публікаваў яго, пакіньце гэтую схему без зменаў, замест таго каб дадаваць канкурэнтны абнаўляльнік, які хістаецца паміж двума адрасамі.
Калі разгортванне публікуе абедзве сям'і адрасоў, чытайце і запіс A, і запіс AAAA. Кожны павінен паказваць на службу, якая сапраўды слухае і дапушчана праз уласны шлях фаервола, а працоўнае супастаўленне IPv4 нічога не кажа пра бок IPv6. Таксама захоўвайце праверкі ідэнтычнасці ў профілі кліента: зменены публічны адрас не з'яўляецца прычынай прымаць сертыфікат або ключ партнёра, які не супадае.
Давядзіце замену звонку
Тэстуйце праз дазволенае знешняе злучэнне і свежую сесію, а не знутры LAN. Унутраны тэст супраць публічнага адраса залежыць ад таго, як маршрутызатар апрацоўвае зварот да ўласнага публічнага адраса, і ідзе іншым шляхам, чым рэальны кліент.
Ідзіце паслядоўнасцю кліента: развяжыце імя, узгадніце тунель, прайдзіце аўтэнтыфікацыю, затым выканайце адну аперацыю з прыватным рэсурсам. Менавіта апошні крок людзі прапускаюць, і толькі ён даказвае зваротны шлях. Калі ўваход паспяховы, а прыватная аперацыя не ўдаецца, параўнайце новы прэфікс LAN, маршруты, якія выбраў кліент, і шлях адказу рэсурсу з вашымі нататкамі перадачы.
Толькі пасля таго, як пройдуць усе чатыры крокі, стары маршрутызатар можна бяспечна вывесці. Адключыце яго, затым паўтарыце знешні тэст яшчэ раз. Састарэлы запіс, які ўсё яшчэ развязваецца ў стары адрас, правальваецца ўжо на першым кроку, і гэта лягчэй дыягнаставаць, пакуль старая прылада яшчэ на паліцы.
Захавайце новае супастаўленне разам з нататкамі пра аднаўленне
Падшыце канчатковае прызначэнне сервера, правіла ўваходу і імя ўладальніка абнаўлення побач з працэдурай лакальнага доступу да маршрутызатара. Наступная замена павінна пачынацца з гэтай старонкі, а не з traceroute.
Калі тунель усё яшчэ не працуе звонку пасля ўсяго вышэйпералічанага, праверце, ці супадае публічны адрас, які паведамляе маршрутызатар, з тым, які развязваюць кліенты. Гэтае адзінае параўнанне аддзяляе праблему DNS ад праблемы перанакіравання, і яно займае менш часу, чым чытанне чарговага кіраўніцтва па перанакіраванні портаў.