WAN-IP het verander en die tonnel het geval: die kontroles in volgorde
Teken die WAN-gebeurtenis aan en kyk dan wat dit nie gevolg het nie: verouderde vertaalinskrywings, roetes wat aan die ou gateway gebind is, eweknieë wat na die ou adres stuur.
Die tonnel val, die router teken 'n herverbinding aan, en niks op die LAN het beweeg nie. 'n Nuwe WAN-adres maak die buitenste verbinding ongeldig sonder om enigiets binne te verander: die kliënt se bronadres het verander, die ou NAT-toestand wys na 'n bron wat nie meer bestaan nie, en die afgeleë eweknie stuur dalk steeds na die vorige adres. Herstel is normale gedrag, en die nuttige vraag is watter toestand nagelaat het om op te dateer.
Noem die gebeurtenis voordat jy die log lees
Kyk wat werklik op die toegangsvlak gebeur het. 'n ISP-herstel van die huurkontrak is een gebeurtenis. 'n PPPoE-sessie wat weer gekoppel het, is 'n ander. 'n Veselmodem wat herbegin het, of 'n WAN-oorskakeling van een opvoer na 'n ander, verander die buitenste adres of sy pad op 'n derde manier. Hulle is nie dieselfde gebeurtenis nie en hulle laat nie dieselfde oorblyfsels nie.
'n Herverbindingslyn in die VPN-log is ook nie bewys van 'n WAN-verandering nie. 'n Ledige tydsverloop, 'n heraanmeldingsinterval en dooie-eweknie-opsporing veroorsaak almal herverbindings sonder enige adresverandering. Vergelyk tydstempels van die toegangslog met die VPN-log voordat jy enigiets aflei, en hou die vergelykingsvenster wyd genoeg om 'n verandering wat gedurende die nag gebeur het, te vang.
Rondswerwing en herverbinding is verskillende protokolle
WireGuard het geauthentiseerde rondswerwing in die protokol ingebou: wanneer 'n eweknie 'n korrek geauthentiseerde pakket van 'n nuwe bronadres ontvang, dateer dit daardie eweknie se eindpunt op. Die WireGuard-vinnigstart beskryf die eweknie-konfigurasie wat dit laat werk, daarom herstel 'n kliënt op 'n veranderende adres dikwels sonder 'n sigbare herbegin.
OpenVPN gedra hom by verstek anders. 'n UDP-sessie kan eindig en weer koppel, en die opsionele float-gedrag laat 'n geauthentiseerde eweknie toe om van 'n nuwe adres voort te gaan waar die konfigurasie dit toelaat. TCP-gebaseerde tonnels is strenger, want die verbinding self is aan die adrespaar gebind. Daardie verskil bepaal of die herstel onsigbaar lyk of elke keer in die log aankondig.
Nie een van die gedrag sê iets oor die toepassings binne nie. 'n Herstelde tonnel herstel nie 'n TCP-sessie wat die eweknie al as dood beskou het nie.
Toestand wat die tonnel nie besit nie
Vertaal- en roetetoestand oorleef die herverbinding op maniere wat mense verras. 'n conntrack-inskrywing wat vir die ou bron geskep is, hou die antwoordpad aan 'n adres vas wat nie meer bestaan nie, en dit verval op sy eie skedule eerder as wanneer die tonnel teruggekom het. Om die tonneldiens te herbegin verkort nie daardie wag nie, so 'n herstelde skakel kan nog 'n rukkie as stukkend lyk.
Roetes en beleidsreëls kan na die ou gateway of koppelvlak verwys. 'n Reëlversameling wat voor 'n WAN-oorskakeling korrek was, kan na 'n toestel wys wat nou af is, wat 'n tonnel oplewer wat as gekoppel rapporteer en verkeer wat nêrens heen gaan nie. Dinamiese DNS vir 'n bediener wat jy aanbied is 'n aparte probleem van 'n kliënt wat 'n nuwe bron kry. Die rekord moet opgedateer word sodat afgeleë kliënte jou kan vind, en geen kliëntkant-konfigurasie vergoed vir 'n adres wat opstroom-vertaling nie sal aanstuur nie.
Orden die kontroles van buite na binne
Die orde hieronder loop van die buitenste verbinding inwaarts, en om by die eerste falende stap te stop is wat dit nuttig maak: elke kontrole sluit die laag bo dit uit. Hou daardie orde selfs wanneer die fout ooglopend lyk.
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
Die eerste opdrag wys die huidige eindpunt en handdruk-ouderdom vir elke eweknie. Die tweede en derde wys of die buitenste koppelvlak en die roete na die eindpunt nog sin maak. Die conntrack-telling is 'n growwe kontrole vir toestand wat van die vorige adres oorgebly het, en die joernaal is waar die rede vir die herverbinding aangeteken word.
Toets dan van 'n LAN-kliënt eerder as van die router. 'n Ping wat deur die router self gestuur word gebruik 'n ander pad as deurgevoerde verkeer, so 'n suksesvolle router-ping bewys die tonnel bestaan en niks oor kliëntbereikbaarheid nie.
Bepaal die verwagte gedrag en skryf dit neer
Herverbind is korrekte gedrag vir die meeste ontplooiings, so die doel is nie om dit te voorkom nie. Bepaal eerder wat gedurende die gaping met verkeer moet gebeur: stop dit, hou dit, of skakel oor na 'n ander pad. Daardie besluit hoort in die firewall en roetebeleid, nie in die VPN-profiel nie.
Teken die toegangsgebeurtenisse en die herverbindingstye saam vir 'n week aan. Herhaalde veranderinge sonder 'n ooreenstemmende toegangsgebeurtenis wys na die toegangsdiens, en om die VPN-profiel te vervang sal nie 'n opvoer regmaak wat aanhou heronderhandel nie. 'n Enkele paar inskrywings in dieselfde minuut beslis die vraag vir daardie voorval en gee die volgende een 'n basislyn.