VPN-то се пресели: зошто вашиот OpenVPN клиент сѐ уште го бира стариот IP
Новиот DNS запис е само еден чекор. Споредете го одговорот на резолверот, адресата што клиентот навистина ја бира и опциите за рестартирање пред да очекувате повторно поврзување.
Доставувачот ја смени вашата јавна адреса, ја ажуриравте динамичната 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 ги наведува сите четири опции со нивниот сопствен опсег, и тоа е контролната листа што треба да се држи покрај профилот.
Обезбедете вонпојасен пат до серверот пред да го рестартирате тунелот што го носи вашиот административен пристап. Таа единствена мерка на претпазливост спречува повеќето инциденти што ги создава ова сценарио.