Overvak ein ruter-VPN utan å stole på éi statuslampe
Peer-tilstand, den valde ruta og ein tillaten applikasjonssond svarar på ulike spørsmål. Varsle på grensa som feila, ikkje på eit grønt ikon.
Statussida seier tilkopla, lampa er grøn, og kontoret når ikkje filserveren. Eitt av desse fakta gjeld tunnelen, det andre vegen gjennom han. Å overvake begge er skilnaden mellom eit varsel du kan handle på og eit du lærer å ignorere.
Fem kontrollar, i rekkjefølgje, frå peer og utover.
Kontroll 1: peer- eller assosiasjonstilstand
Kvart protokoll eksponerer sin eigen tilstand. WireGuard viser siste handtrykk og overføringsteljarar per peer gjennom wg show. OpenVPN skriv sesjonstilstand til statusfila eller administrasjonsgrensesnittet, og IPsec eksponerer tryggingsassosiasjonar gjennom verktøy som ipsec statusall. Fella er å lese eit tidsstempel som ein dom: ein inaktiv WireGuard-peer utan noko å sende vil ikkje handtrykke nyleg, og det er ikkje eit utfall.
Samanlikn tidsstempelet med forventa trafikk og keepalive-innstillingar før du tilkallar nokon.
Kontroll 2: den valde ruta
Eit tunnegrensesnitt kan eksistere medan ingenting rutes inn i det. Sjekk vidaresendingstabellen for destinasjonen du bryr deg om, ikkje for tunnelens eige subnett. Viss prefikset manglar eller peikar ein annan stad, er peer-tilstanden irrelevant.
Den kontrollen fangar feilen ei statuslampe aldri viser.
Ein nyttig andre kontroll samanliknar også kjeldeadressa. ip route get 10.20.5.10 returnerer neste hopp, grensesnittet og den føretrekte kjelda, og ei feil kjelde er nok til å bryte returtrafikken i den fjerne enden. Noter det forventa trippelet éin gong, og varsle deretter når eit element endrar seg. Den eine linja fangar NAT-endringar, grensesnittssvingingar og feil i policybasert ruting.
Kontroll 3: ein tillaten applikasjonsveg
Test noko som er representativt for det faktiske kravet. Ein ping frå ruteren startar frå ruterens eigen adresse og policy, som kan avvike frå vidaresendt LAN-trafikk, og mange vertar avgrensar ICMP. Viss kravet er ein privat teneste, test den tenesta på den ekte porten hennar.
Hald sondens volum beskjedent. Ei overvakingsløkke bør ikkje bli trafikken ho måler.
Kontroll 4: kva endra seg og når
Korreler WAN-endringar, nøkkelfornyingar, ruteuttrekk og applikasjonsfeil på éi tidslinje. Skil ein tunnelfeil frå ei reserverute som stille gjenopprettar vanleg internettilgang, fordi begge gir identiske brukarrapportar og motsette diagnosar. Tidssonefeil vil snu rekkjefølgja, så normaliser før du samanliknar. Tidslinja er det som gjer fire kontrollar til ei årsak.
Ta vare på loggar for overgangane, ikkje for nyttelasta.
Kontroll 5: varselet skal nemne grensa
Eit varsel som seier VPN nede sender nokon til feil stad halvparten av tida. Eit som seier peer-handtrykket er utdatert i tolv minutt, ruta til 10.20.0.0/16 manglar, eller sonden til port 445 feilar, peikar på ein bestemt kontroll.
Hald driftsteljarar i staden for å bla gjennom nyttelaster. Teljarar svarar på overvakingsspørsmålet utan å samle inn innhald du ikkje treng.
Og la failover-policyen avgjere kva som skjer vidare. Overvaking skal identifisere kva grense som feila, ikkje autorisere ei brei omkøyring kvar gong ein sond feilar. OpenVPN 2.6-handboka dokumenterer statusfila og administrasjonsgrensesnittet som gjer den første kontrollen skriptbar.