VPN пераехаў: чаму ваш кліент OpenVPN усё яшчэ набірае стары IP

Правайдэр змяніў ваш публічны адрас, вы абнавілі дынамічны запіс DNS, а кліент усё яшчэ не можа падключыцца. Звонку гэта выглядае так, нібы запіс не распаўсюдзіўся. Часцей за ўсё запіс у парадку, а кліент набірае адрас, які ён вызначыў да пераезду, бо працуючы тунель і захаваны профіль маюць кожны сваё ўяўленне пра тое, дзе жыве сервер. Тры ўзроўні павінны ўзгадніцца, і абнаўляюцца яны па розных графіках.

Глядзіце на тое, што набірае профіль, а не на тое, што кажа DNS

Адкрыйце злучэнне, якое вы фактычна выкарыстоўваеце, і прачытайце радок remote. Лікавы адрас там ніколі не ідзе за абнаўленнем імя хоста, якім бы правільным ні стаў запіс.

Затым праверце, ці профіль, які вы змянілі, — той, які загрузіў кліент. Імпартаваныя профілі — звычайная справа: менеджар мог узяць копію месяцы таму і трымаць уласную версію, таму файл у вашым каталогу загрузак і запіс у праграме могуць разыходзіцца. Параўнайце канчатковы пункт у ўласных звестках аб злучэнні кліента, перш чым увогуле займацца DNS.

Два файлы, адзін канчатковы пункт — звычайная знаходка тут.

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

Прачытайце наступную спробу злучэння кліента

Перазапусціце злучэнне з падрабязным журналам і прачытайце радок, дзе названы адрас, з якім яно будзе кантактаваць. Менавіта гэтае значэнне мае сэнс, а не тое, што вызначыў ваш браўзер.

Кэш рэзалвера можа ўсё яшчэ трымаць папярэдні адказ, а некаторыя сеткі трымаюць яго даўжэй, чым патрабуе TTL запісу. Запытвайце рэзалвер, які кліент фактычна выкарыстоўвае, а не публічны, які вы правяралі з іншага месца.

Калі журнал паказвае новы адрас, а злучэнне ўсё яшчэ не ўдаецца, праблема перамясцілася: пакет ідзе кудысьці, і ніхто не адказвае. Гэта пытанне слухача, фаервала або перанакіравання порта, і яно знаходзіцца на баку сервера, а не ў шляху развязання кліента. Трымайце гэтыя два збоі асобна, бо стаўленне да недаступнага слухача як да праблемы DNS двойчы праводзіць вас па адным і тым жа крузе.

Ведайце, які перазапуск вы робіце

Не ўсе перазапускі захоўваюць аднолькавы стан, таму змена адраса можа паводзіць сябе па-рознаму ў залежнасці ад таго, як перапрацоўваецца працэс. Мяккі перазапуск, выкліканы сігналам, захоўвае больш кантэксту папярэдняй сесіі, а поўны прыпынак і запуск пачынаецца зноў з канфігурацыі. Калі вы правяраеце, ці кліент паўторна развяжа адрас, вам патрэбны шлях, які пачынаецца з канфігурацыі.

Налады захавання таксама важныя, бо яны створаны трымаць тое, што было аўтэнтыфікавана, а не гнацца за новымі адрасамі.

Найчысцейшы тэст — свежы запуск з патрэбнага профілю, а затым позірк на радок журнала, дзе названы канчатковы пункт. Усё, што вы даведаецеся з часткова захаванай сесіі, — гэта сцвярджэнне пра тую сесію.

Чатыры варыянты і іх асобныя задачы

remote з імем хоста — гэта налада, якая ўвогуле робіць паўторнае развязанне магчымым; літаральны адрас у гэтым радку выключае яго. resolv-retry кіруе тым, што адбываецца пры няўдалым пошуку, і 2.6 ужо па змаўчанні робіць яго бясконцым. Таму яго даданне нічога не змяняе, і ён ніколі не плануе перыядычную праверку іншага адказу. Хто кажа, што ён апытвае новыя адрасы, той блытае аднаўленне са свежасцю.

persist-remote-ip — гэта пра бесперапыннасць, а не пра свежасць: ён паўторна выкарыстоўвае канчатковы пункт, які апошнім аўтэнтыфікаваўся, праз мяккія перазапускі, якія падтрымлівае. Падчас тэставання пераезду гэта супрацьлегласць таму, што вы хочаце. Адключыце яго для тэсту, калі вашая зборка яго ўключае, а затым аднавіце, калі новы канчатковы пункт даказаны. Пакінуты ўключаным, ён можа нічога не сказаць вам пра DNS пры ўдалым перападключэнні.

float прымае аўтэнтыфікаванага партнёра, чый адрас змяніўся пасярод сесіі, і толькі ў канфігурацыях, якія гэта падтрымліваюць. Ён не абнаўляе DNS і не пойдзе за зменай правайдэра сам. Разглядайце яго як функцыю ўстойлівасці для партнёраў, якія блукаюць, а не як механізм дынамічных адрасоў для сервераў.

Пацвердзіце новы канчатковы пункт, перш чым вінаваціць кліент

Звонку вашай сеткі праверце, што новы адрас мае слухача на наладжаным порце і што перанакіраванне правайдэра паказвае на яго. Правільны запіс A для машыны без адкрытага порта дае менавіта той сімптом, які людзі прыпісваюць кэшаванню.

Затым перападключыцеся і праверце дзве рэчы: кліент аўтэнтыфікаваўся супраць чаканага сертыфіката сервера, і сесія дасягае рэсурсу, які вы мелі на ўвазе. Змена адраса не зніжае патрабаванні да ідэнтычнасці, а злучэнне, якое паспяхова ідзе да няправільнага канчатковага пункта, горш за тое, якое не ўдаецца. Дапаможнік OpenVPN 2.6 пералічвае ўсе чатыры варыянты з іх уласнай сферай дзеяння, і гэта кантрольны спіс, які трэба трымаць побач з профілем.

Трымайце пазапалосны шлях на сервер, перш чым перазапусціць тунель, які нясе ваш адміністрацыйны доступ. Гэтая адна засцярога прадухіляе большасць інцыдэнтаў, якія стварае гэты сцэнар.