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 изброява и четирите опции със собствения им обхват и това е контролният списък, който да държите до профила.

Пазете извънлентов път до сървъра, преди да рестартирате тунела, който носи административния ви достъп. Тази единствена предпазна мярка предотвратява повечето инциденти, които този сценарий създава.