Ziet de router-VPN er na een stroomstoring goed uit? Test deze vier lagen
Een hersteld profiel is geen werkende tunnel. Controleer na een stroomstoring de WAN-gereedheid, de klok, de tunnelstatus en een apparaat stroomafwaarts voordat u het lampje vertrouwt.
Een router die na een storing oplicht, heeft zijn configuratie hersteld, niet zijn connectiviteit. Na een stroomstoring kan een router zijn opgeslagen VPN-profiel herstellen voordat de afhankelijkheden die dat profiel nodig heeft gereed zijn: de modem stroomopwaarts is mogelijk nog aan het trainen, de klok kan verkeerd staan en de authenticatie is misschien niet voltooid. Het lampje op het dashboard en de opgeslagen configuratie beschrijven een bedoeling, geen werkende tunnel. Controleer de vier lagen hieronder in volgorde in plaats van het profiel te vervangen, want dat doen mensen als tweede en betreuren ze als eerste.
Alles hier gaat ervan uit dat u ter plaatse bent of een toegang heeft die niet afhankelijk is van de tunnel die u test. Als dat niet zo is, regel dat dan voor de volgende storing.
Eerste laag: is de WAN echt terug
Begin bij de modem, niet bij het dashboard van de router. Een router die het opstarten voltooit voordat zijn modem heeft getraind, toont een gezonde interface zonder iets erachter, en de tunnel heeft geen peer om te bereiken. Bevestig dat de modem echt doorstuurt en bevestig dan dat de router de WAN-instellingen heeft overgenomen die u verwacht. Controleer ook of het WAN-adres is veranderd: een dynamisch adres dat anders terugkomt kan een op adres gebaseerde regel of een externe toelatingslijst ongeldig maken, en van binnen het netwerk ziet dat eruit als een VPN-fout.
Sommige toegangsnetwerken vereisen na een storing ook een nieuwe toelatingsstap. Lees de clientlog voor de eerste faalfase in plaats van te gissen: de eerste fout noemt de laag, en alles daarna is gevolg. Noteer het adres en het toelatingsresultaat in het ticket, want beide bepalen of hetzelfde profiel morgen werkt. Een gewijzigd adres is een correctie van vijf minuten en een raadsel van twee uur.
Tweede laag: controleer de klok voor het certificaat
Een verkeerde klok verstoort de geldigheid van het certificaat en alles wat tijdgebonden is, en een ingebed apparaat dat opstart zonder werkende tijdbron kan een tijdje op een oude datum blijven staan. Certificaatvalidatie mislukt dan om een reden die niets met de inloggegevens te maken heeft. Een geldigheidsfout waarvan de datums jaren afwijken wijst op de klok; dezelfde fout met actuele datums wijst op het certificaat.
date -u
chronyc tracking
Gebruik het ondersteunde tijdsherstelproces en bevestig de klok van de router voordat u het profiel aanraakt. Validatie uitschakelen om de fout te omzeilen verandert een tijdelijk ordeningsprobleem in een blijvende verzwakking, en dat is de meest voorkomende slechte correctie in dit scenario. Heeft het apparaat geen klok op batterijen, dan is de opstartvolgorde belangrijk: het heeft netwerktoegang nodig voordat het de tijd kan synchroniseren, en tijd voordat het een tunnel kan valideren. Die volgorde is wat er moet worden hersteld als dezelfde fout na elke storing terugkomt.
Derde laag: lees wat de tunnel zegt
Controleer de eigen status van de tunnel en het resultaat van de handshake of authenticatie, niet of de interface omhoog is. Een interface kan bestaan zonder gevestigde peer, en een client kan verbonden tonen terwijl sleutelvernieuwing mislukt. Scheid transporttime-outs van expliciete afwijzingen: een time-out suggereert dat het pad of de peer nog niet bereikbaar is, terwijl een afwijzing betekent dat de andere kant heeft geantwoord en geweigerd, meestal vanwege inloggegevens, een certificaat of een peer-identiteit die niet meer klopt. Een gebruiker door een wachtwoordreset sturen voor een time-out kost iedereen de middag.
Houd de laatst bekende goede configuratie bij de hand om velden te vergelijken in plaats van ze opnieuw op te bouwen. Is een veld gewijzigd, dan is die wijziging de bevinding. Vergelijk het veld voor veld met de herstelde, in plaats van alleen de herstelde te lezen. De meeste verrassingen na een storing zijn een veld dat stilletjes terugviel op een sjabloonstandaard.
Vierde laag: test vanaf een apparaat stroomafwaarts
Open een onschuldige toegestane bron vanaf een client achter de router en bevestig dan welke uitgang of privéroute het verkeer werkelijk gebruikte. Controleer DNS en elke adresfamilie waarvan u zegt dat die gedekt is, want de eigen test van de router kan slagen terwijl het clientbeleid nog fout is — de test gebruikt vaak een andere bron, een andere tabel of een ander resolverpad.
curl -s https://ifconfig.me
nslookup example.com
Als de tunnel ligt en niet alleen verkeerd is geconfigureerd, beslis dan of getroffen clients moeten worden geblokkeerd of een goedgekeurde terugval mogen gebruiken. Die keuze hoort in het failoverplan voor een storing, niet in een chatthread tijdens een storing. Schrijf de waargenomen uitgang en resolver in het storingsticket. Twee regels besparen de volgende persoon nu een uur gissen naar welk pad tijdens het venster actief was.
Wat u moet herstellen zodat de volgende storing korter is
Als de fout terugkomt, is de correctie de volgorde, niet de configuratie: breng de WAN omhoog, dan de tijd, dan de tunnel, dan het clientbeleid. De meeste routers drukken dat uit als een afhankelijkheid of een vertraging, en een korte bewuste vertraging wint het van het herschrijven van een profiel.
Herhaal daarna de normale herstarttest nadat u het hebt gewijzigd, inclusief de controle aan de clientkant. Een herstarttest die alleen naar het dashboard van de router kijkt, test de minst informatieve van de vier lagen.