Vasgehaakte VPN ná 'n herbegin van die router: drie dinge wat verander het

Die router klaar begin, die skootrekenaar sluit by dieselfde SSID aan, en die VPN staan op verbind sonder dat iets beweeg. Die gestoorde profiel is ongeskonde. Wat daaronder verval het, was die pad, en die kliënt hou nog die toestand vas wat hy vir die ou een gebou het.

Drie voorwaardes bepaal die oplossing. Kontroleer hulle in volgorde, want die latere is vermorsde moeite as die eerste die stilstand al verklaar.

Voorwaarde een: die plaaslike adres het verander

Ná 'n herbegin kan die masjien 'n ander adres kry. 'n VPN wat met 'n vaste plaaslike eindpunt opgestel is, hou dan aan om 'n aansluiting te gebruik wat nie meer bestaan nie. Dieselfde geld vir 'n kliënt wat sy sokkel aan die ou adres gebind het. Die tonnelkoppelvlak kan op bly terwyl elke pakket wat dit produseer nêrens heen gaan nie.

Vergelyk die adres wat die kliënt gebruik met die adres wat die koppelvlak tans het. 'n Standaardroete wat na 'n gwadres wys wat ook verander het, is dieselfde soort probleem met 'n ander naam.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Voorwaarde twee: die vertaalde kartering is weg

Tuisroeteerders vertaal uitgaande strome, en daardie karterings leef in die geheue. 'n Herbegin wis elkeen van hulle. Dit is onskadelik vir 'n nuwe verbinding en noodlottig vir 'n tonnel wat glo sy bestaande stroom is nog geldig. Die eweknie sien dan niks, so die kliënt kry nooit 'n fout wat hy kan hanteer nie.

Dit is waar 'n tonnel sonder keepalives stil vasval eerder as om hardop te misluk. WireGuard se gedokumenteerde beperkinge beskryf dieselfde vorm van mislukking. Verkeerde eindpunttoestand lewer weggevalde pakkette eerder as 'n diagnose.

'n Aanhoudende keepalive van 25 sekondes is die gewone versagting, want dit verfris die kartering voordat 'n ledige tydsverloop kan verstryk. Dit herstel nie 'n kartering wat reeds weg is nie. Koppel die keepalive aan herverbindingslogika eerder as om dit as 'n oplossing te behandel.

Voorwaarde drie: die publieke adres het verander

As die router se eie eksterne adres verander het, sien enigiets aan die ander kant wat volgens bronadres filter, nou 'n ander eweknie. Die tonnel kan opkom en die bediener kan steeds die verkeer verwerp, wat soos 'n stukkende kliënt lyk en eintlik 'n beleid aan die ander kant is.

Teken die eksterne adres voor en ná die herbegin op. Wanneer die twee verskil, skuif die vraag van die kliënt na wie ook al die toelatingslys onderhou, en om aanmeldgegewens op die skootrekenaar te herstel kan nie help nie.

Herstel in die regte volgorde

Voltooi eers enige vereiste aanmelding by 'n captive portal, en laat die kliënt dan herverbind via sy ondersteunde prosedure eerder as om die proses te doodmaak. Let op of identiteit en dataverkeer albei herstel, want dit is twee verskillende stadiums van dieselfde verbinding.

'n Gekaste bladsy bewys niks, en 'n kletsapp wat vanself herverbind het ook nie. Toets die eindpunt waaroor jy regtig omgee met 'n nuwe versoek. Hou die direkte-verkeer-beleid in werking tydens die onderbreking, want 'n herverbindingspoging is nie 'n blok nie.

Wanneer dit ná elke herbegin herhaal, maak die rekord meer saak as die herprobeerslag. Noteer die plaaslike adres, die gwadres, die eksterne adres en die kliënttoestand voor en ná, en vergelyk dan die twee kolomme. Dit verander 'n vae klag in 'n lewensiklusfout wat iemand kan regmaak, en dit keer dat die sertifikate vir 'n derde keer oor 'n karteringstydsverloop vervang word.