Övervaka en router-VPN utan att lita på en enda statuslampa
Peer-status, den valda rutten och en tillåten applikationssond svarar på olika frågor. Larma på gränsen som misslyckades, inte på en grön ikon.
Statussidan säger ansluten, lampan är grön och kontoret når inte filservern. Ett av dessa fakta handlar om tunneln, det andra om vägen genom den. Att övervaka båda är skillnaden mellan ett larm du kan agera på och ett du lär dig ignorera.
Fem kontroller, i ordning, från peeren och utåt.
Kontroll 1: peer- eller associationstillstånd
Varje protokoll exponerar sitt eget tillstånd. WireGuard visar senaste handskakningen och överföringsräknare per peer via wg show. OpenVPN skriver sessionstillstånd till sin statusfil eller administrationsgränssnitt, och IPsec exponerar säkerhetsassociationer via verktyg som ipsec statusall. Fällan är att läsa en tidsstämpel som en dom: en inaktiv WireGuard-peer utan något att skicka handskakar inte nyligen, och det är inte ett avbrott.
Jämför tidsstämpeln med förväntad trafik och keepalive-inställningar innan du kallar på någon.
Kontroll 2: den valda rutten
Ett tunngränssnitt kan finnas medan ingenting routas in i det. Kontrollera vidarebefordringstabellen för destinationen du bryr dig om, inte för tunneln eget subnät. Om prefixet saknas eller pekar någon annanstans är peer-statusen irrelevant.
Den kontrollen fångar felet som en statuslampa aldrig visar.
En användbar andra kontroll jämför också källadressen. ip route get 10.20.5.10 returnerar nästa hopp, gränssnittet och den föredragna källan, och en felaktig källa räcker för att bryta returtrafiken i den bortre änden. Anteckna den förväntade trippeln en gång och larma sedan när något element ändras. Den enda raden fångar NAT-ändringar, gränssnittsfladder och fel i policybaserad routing.
Kontroll 3: en tillåten applikationsväg
Testa något som representerar det faktiska kravet. En ping från routern utgår från routerns egen adress och policy, som kan skilja sig från vidarebefordrad LAN-trafik, och många värdar begränsar ICMP. Om kravet är en privat tjänst, testa den tjänsten på dess riktiga port.
Håll sondens volym blygsam. En övervakningsloop bör inte bli trafiken den mäter.
Kontroll 4: vad ändrades och när
Korrelera WAN-ändringar, nyckelbyten, ruttillbakadragningar och applikationsfel på en enda tidslinje. Skilj ett tunnelfel från en reservrutt som tyst återställer vanlig internetåtkomst, eftersom båda ger identiska användarrapporter och motsatta diagnoser. Tidszonsfel vänder ordningen, så normalisera före jämförelse. Tidslinjen är det som förvandlar fyra kontroller till en orsak.
Bevara loggar för övergångarna, inte för nyttolasten.
Kontroll 5: larmet ska namnge gränsen
Ett larm som säger VPN nere skickar någon till fel ställe hälften av gångerna. Ett som säger att peer-handskakningen är inaktuell i tolv minuter, rutten till 10.20.0.0/16 saknas eller sonden till port 445 misslyckas pekar på en specifik kontroll.
Håll driftmätare i stället för att bläddra i nyttolaster. Mätare svarar på övervakningsfrågan utan att samla in innehåll du inte behöver.
Och låt failover-policyn avgöra vad som händer härnäst. Övervakning ska identifiera vilken gräns som misslyckades, inte auktorisera en bred kringgång varje gång en sond misslyckas. OpenVPN 2.6-handboken dokumenterar statusfilen och administrationsgränssnittet som gör den första kontrollen skriptbar.