Ser routerns VPN bra ut efter ett strömavbrott? Testa dessa fyra lager
En återställd profil är inte en fungerande tunnel. Efter ett strömavbrott, kontrollera WAN-beredskap, klockan, tunnels tillstånd och en enhet längre ned innan du litar på ljuset.
En router som lyser upp efter ett avbrott har återställt sin konfiguration, inte sin anslutning. Efter ett strömavbrott kan en router återställa sin sparade VPN-profil innan de beroenden som profilen behöver är klara: modemet uppströms kan fortfarande träna, klockan kan vara fel och autentiseringen kan vara ofullständig. Lampan i panelen och den sparade konfigurationen beskriver avsikt, inte en fungerande tunnel. Kontrollera de fyra lagren nedan i ordning i stället för att byta ut profilen, för det är vad folk gör som andra och ångrar som första.
Allt här förutsätter att du är på plats eller har en väg in som inte beror på tunneln du testar. Om inte, ordna det före nästa avbrott.
Första lagret: är WAN verkligen tillbaka
Börja med modemet, inte med routerns panel. En router som slutför uppstarten innan modemet har tränat visar ett friskt gränssnitt utan något bakom, och tunneln har ingen motpart att nå. Bekräfta att modemet faktiskt vidarebefordrar och bekräfta sedan att routern har tagit de WAN-inställningar du förväntar dig. Kontrollera också om WAN-adressen har ändrats: en dynamisk adress som kommer tillbaka annorlunda kan ogiltigförklara en adressbaserad regel eller en extern tillåtelselista, och inifrån nätet ser det ut som ett VPN-fel.
Vissa åtkomstnät kräver också ett nytt upptagningselement efter ett avbrott. Läs klientloggen för det första felet i stället för att gissa: det första felet namnger lagret, och allt efteråt är en konsekvens. Skriv adressen och upptagningsresultatet i ärendet, eftersom båda avgör om samma profil fungerar imorgon. En ändrad adress är en fem minuters rättelse och ett två timmars mysterium.
Andra lagret: kontrollera klockan före certifikatet
En felaktig klocka stör certifikatets giltighet och allt tidsbaserat, och en inbyggd enhet som startar utan en fungerande tidskälla kan stå kvar på ett gammalt datum ett tag. Certifikatvalideringen misslyckas då av en anledning som inte har något med inloggningsuppgifterna att göra. Ett giltighetsfel vars datum är år fel pekar på klockan; samma fel med aktuella datum pekar på certifikatet.
date -u
chronyc tracking
Använd den stödda tidsåterställningsprocessen och bekräfta routerns klocka innan du rör profilen. Att stänga av validering för att komma förbi felet gör ett tillfälligt ordningsproblem till en permanent försvagning, och det är den vanligaste dåliga rättelsen i det här scenariot. Om enheten inte har en batteridriven klocka spelar startordningen roll: den behöver nätverksåtkomst innan den kan synkronisera tiden, och tid innan den kan validera en tunnel. Det är den ordningen som måste rättas om samma fel återkommer efter varje avbrott.
Tredje lagret: läs vad tunneln säger
Kontrollera tunnelns eget tillstånd och resultatet av dess handskakning eller autentisering, inte att gränssnittet är uppe. Ett gränssnitt kan finnas utan en etablerad motpart, och en klient kan visa ansluten medan nyckelbytet misslyckas. Skilj transporttidsgränser från tydliga avvisningar: en tidsgräns antyder att vägen eller motparten ännu inte är nåbar, medan en avvisning betyder att andra sidan svarade och vägrade, oftast på grund av inloggningsuppgifter, ett certifikat eller en motpartsidentitet som inte längre stämmer. Att skicka användaren genom en lösenordsåterställning för en tidsgräns kostar alla eftermiddagen.
Ha den senast kända fungerande konfigurationen till hands så att du kan jämföra fält i stället för att bygga upp dem igen. Om ett fält har ändrats är den ändringen fyndet. Jämför det fält för fält med den återställda i stället för att bara läsa den återställda. De flesta överraskningar efter ett avbrott är ett fält som tyst föll tillbaka till en mallstandard.
Fjärde lagret: testa från en enhet längre ned
Öppna en ofarlig tillåten resurs från en klient bakom routern och bekräfta sedan vilken utgång eller privat rutt trafiken faktiskt använde. Kontrollera DNS och varje adressfamilj du hävdar att du täcker, eftersom routerns egen sond kan lyckas medan klientpolicyn fortfarande är fel — sonden använder ofta en annan källa, en annan tabell eller en annan resolverväg.
curl -s https://ifconfig.me
nslookup example.com
Om tunneln ligger nere och inte bara är felkonfigurerad, avgör om berörda klienter måste blockeras eller får använda en godkänd reservväg. Det valet hör till redundansplanen före ett avbrott, inte till en chattråd under ett. Skriv den observerade utgången och resolvern i avbrottsärendet. Två rader nu sparar nästa person en timmes gissningar om vilken väg som var aktiv i fönstret.
Vad som ska rättas så att nästa avbrott blir kortare
Om felet återkommer är rättelsen ordningen, inte konfigurationen: få upp WAN, sedan tid, sedan tunneln, sedan klientpolicyn. De flesta routrar uttrycker det som ett beroende eller en fördröjning, och en kort avsiktlig fördröjning slår en omskrivning av profilen.
Upprepa sedan det vanliga omstartstestet efter att du ändrat det, inklusive kontrollen på klientsidan. Ett omstartstest som bara tittar på routerns panel testar det minst informativa av de fyra lagren.