Overvåk en ruter-VPN uten å stole på én statuslampe
Peer-tilstand, den valgte ruten og en tillatt applikasjonssonde svarer på ulike spørsmål. Varsle på grensen som feilet, ikke på et grønt ikon.
Statussiden sier tilkoblet, lampen er grønn, og kontoret når ikke filserveren. Ett av disse faktaene handler om tunnelen, det andre om veien gjennom den. Å overvåke begge er forskjellen mellom et varsel du kan handle på og et du lærer å ignorere.
Fem kontroller, i rekkefølge, fra peer og utover.
Kontroll 1: peer- eller assosiasjonstilstand
Hver protokoll eksponerer sin egen tilstand. WireGuard viser siste håndtrykk og overføringstellere per peer gjennom wg show. OpenVPN skriver sesjonstilstand til statusfilen eller administrasjonsgrensesnittet, og IPsec eksponerer sikkerhetsassosiasjoner gjennom verktøy som ipsec statusall. Fellen er å lese et tidsstempel som en dom: en inaktiv WireGuard-peer uten noe å sende vil ikke håndhilse nylig, og det er ikke et utfall.
Sammenlign tidsstempelet med forventet trafikk og keepalive-innstillinger før du tilkaller noen.
Kontroll 2: den valgte ruten
Et tunnegrensesnitt kan eksistere mens ingenting rutes inn i det. Sjekk videresendingstabellen for destinasjonen du bryr deg om, ikke for tunnelens eget subnett. Hvis prefikset mangler eller peker et annet sted, er peer-tilstanden irrelevant.
Den kontrollen fanger feilen en statuslampe aldri viser.
En nyttig andre kontroll sammenligner også kildeadressen. ip route get 10.20.5.10 returnerer neste hopp, grensesnittet og den foretrukne kilden, og en feil kilde er nok til å bryte returtrafikken i den fjerne enden. Noter det forventede trippelet én gang, og varsle deretter når et element endres. Den ene linjen fanger NAT-endringer, grensesnittsvingninger og feil i policybasert ruting.
Kontroll 3: en tillatt applikasjonsvei
Test noe som er representativt for det faktiske kravet. En ping fra ruteren starter fra ruterens egen adresse og policy, som kan avvike fra videresendt LAN-trafikk, og mange verter begrenser ICMP. Hvis kravet er en privat tjeneste, test den tjenesten på dens ekte port.
Hold sondens volum beskjedent. En overvåkingsløkke bør ikke bli trafikken den måler.
Kontroll 4: hva endret seg og når
Korrelér WAN-endringer, nøkkelfornyelser, ruteuttrekk og applikasjonsfeil på én tidslinje. Skill en tunnelfeil fra en reserverute som stille gjenoppretter vanlig internettilgang, fordi begge gir identiske brukerrapporter og motsatte diagnoser. Tidssonefeil vil snu rekkefølgen, så normaliser før du sammenligner. Tidslinjen er det som gjør fire kontroller til en årsak.
Bevar logger for overgangene, ikke for nyttelasten.
Kontroll 5: varselet skal navngi grensen
Et varsel som sier VPN nede sender noen til feil sted halvparten av tiden. Et som sier peer-håndtrykket er utdatert i tolv minutter, ruten til 10.20.0.0/16 mangler, eller sonden til port 445 feiler, peker på en bestemt kontroll.
Hold driftstellere i stedet for å bla gjennom nyttelaster. Tellere svarer på overvåkingsspørsmålet uten å samle inn innhold du ikke trenger.
Og la failover-policyen bestemme hva som skjer videre. Overvåking skal identifisere hvilken grense som feilet, ikke autorisere en bred omgåelse hver gang en sonde feiler. OpenVPN 2.6-håndboken dokumenterer statusfilen og administrasjonsgrensesnittet som gjør den første kontrollen skriptbar.