WAN IP се променио и тунел је пао: провере по реду

Тунел падне, рутер забележи поновно повезивање, а на LAN-у се ништа није померило. Нова WAN адреса поништава спољну везу без икакве промене унутра: изворна адреса клијента се променила, старо NAT стање показује на извор који више не постоји, а удаљени партнер можда још шаље на претходну адресу. Опоравак је нормално понашање, а корисно питање је које стање није ажурирано.

Именујте догађај пре него што прочитате дневник

Проверите шта се заиста догодило на приступном слоју. Обнова ISP закупа је један догађај. PPPoE сесија која се поново повезала је други. Рестартовани оптички модем, или WAN пребацивање са једног улинка на други, мења спољну адресу или њену путању на трећи начин. То није исти догађај и не остављају исти талог.

Линија поновног повезивања у VPN дневнику такође није доказ WAN промене. Тајмаут мировања, интервал поновне аутентификације и откривање мртвог партнера сви производе поновна повезивања без икакве промене адресе. Упоредите временске ознаке из приступног дневника са VPN дневником пре него што било шта закључите, и држите прозор поређења довољно широким да ухватите промену која се догодила током ноћи.

Роаминг и поновно повезивање су различити протоколи

WireGuard има уграђени аутентификовани роаминг: када партнер прими исправно аутентификован пакет са нове изворне адресе, ажурира крајњу тачку тог партнера. WireGuard брзи почетак описује конфигурацију партнера која то омогућава, због чега се клијент на променљивој адреси често опоравља без видљивог рестарта.

OpenVPN се подразумевано понаша другачије. UDP сесија може да се заврши и поново повеже, а опционо float понашање омогућава аутентификованом партнеру да настави са нове адресе тамо где конфигурација то дозвољава. Тунели засновани на TCP-у су строжи, јер је сама веза везана за пар адреса. Та разлика одлучује да ли опоравак изгледа невидљиво или се сваки пут најави у дневнику.

Ни једно понашање не говори ништа о апликацијама унутра. Опорављени тунел не враћа TCP сесију коју је партнер већ сматрао мртвом.

Стање које тунел не поседује

Стање превода и рутирања преживљава поновно повезивање на начине који изненађују људе. conntrack унос створен за стари извор држи путању одговора усидрену на адресу која више не постоји, и истиче по сопственом распореду, а не када се тунел вратио. Рестартовање услуге тунела не скраћује то чекање, па поправљена веза још неко време може изгледати покварено.

Руте и правила политике могу референцирати стари гејтвеј или интерфејс. Скуп правила који је био исправан пре WAN пребацивања може показивати на уређај који је сада искључен, што ствара тунел који се пријављује као повезан и саобраћај који никуда не иде. Динамички DNS за сервер који хостујете одвојен је проблем од клијента који добија нови извор. Запис треба ажурирати да би вас удаљени клијенти нашли, а ниједна конфигурација на страни клијента не надокнађује адресу коју превод даље узводно неће проследити.

Поређајте провере од спољашњег ка унутрашњем

Редослед испод иде од спољне везе ка унутра, и заустављање на првом кораку који не успе је оно што га чини корисним: свака провера искључује слој изнад себе. Држите тај редослед чак и када квар изгледа очигледно.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Прва наредба показује тренутну крајњу тачку и старост руковања за сваког партнера. Друга и трећа показују да ли спољни интерфејс и рута до крајње тачке још имају смисла. conntrack број је груба провера стања заосталог од претходне адресе, а дневник је место где се бележи разлог поновног повезивања.

Затим тестирајте са LAN клијента, а не са рутера. Ping који шаље сам рутер користи другачију путању од прослеђеног саобраћаја, па успешан ping са рутера доказује да тунел постоји и ништа о доступности клијента.

Одредите очекивано понашање и запишите га

Поновно повезивање је исправно понашање за већину поставки, па циљ није да се спречи. Одлучите уместо тога шта треба да се догоди са саобраћајем током прекида: да се заустави, задржи или пребаци на другу путању. Та одлука припада заштитном зиду и политици рутирања, не VPN профилу.

Бележите приступне догађаје и времена поновног повезивања заједно недељу дана. Поновљене промене без одговарајућег приступног догађаја указују на приступну услугу, а замена VPN профила неће поправити улинк који стално изнова преговара. Један пар уноса у истом минуту решава питање за тај инцидент и даје следећем основну линију.