Overvåg en router-VPN uden at stole på én statuslampe
Peer-tilstand, den valgte rute og en tilladt applikationssonde besvarer forskellige spørgsmål. Alarmér på den grænse, der fejlede, ikke på et grønt ikon.
Statussiden siger forbundet, lampen er grøn, og kontoret kan ikke nå filserveren. Et af de fakta handler om tunnelen, det andet om vejen igennem den. At overvåge begge er forskellen mellem en alarm, du kan handle på, og en, du lærer at ignorere.
Fem kontroller, i rækkefølge, fra peer og udad.
Kontrol 1: peer- eller associationstilstand
Hver protokol viser sin egen tilstand. WireGuard viser det seneste handshake og overførselsstallere for hver peer gennem wg show. OpenVPN skriver sessionstilstand til sin statusfil eller administrationsgrænseflade, og IPsec viser sikkerhedsassociationer gennem værktøjer som ipsec statusall. Fælden er at læse et tidsstempel som en dom: en inaktiv WireGuard-peer uden noget at sende vil ikke lave handshake for nylig, og det er ikke et udfald.
Sammenlign tidsstemplet med forventet trafik og keepalive-indstillinger, før du tilkalder nogen.
Kontrol 2: den valgte rute
En tunnelegrænseflade kan findes, mens intet router ind i den. Tjek videresendingstabellen for den destination, du bekymrer dig om, ikke for tunnelens eget subnet. Hvis præfikset mangler eller peger andre steder hen, er peer-tilstanden irrelevant.
Den kontrol fanger den fejl, en statuslampe aldrig viser.
En nyttig anden kontrol sammenligner også kildeadressen. ip route get 10.20.5.10 returnerer næste hop, grænsefladen og den foretrukne kilde, og en forkert kilde er nok til at bryde returtrafikken i den fjerne ende. Notér den forventede trippel én gang, og alarmér så, når et element ændres. Den ene linje fanger NAT-ændringer, grænsefladeflaps og policy-routing-fejl.
Kontrol 3: en tillad applikationsvej
Test noget, der er repræsentativt for det faktiske krav. Et ping fra routeren starter fra routerens egen adresse og politik, som kan afvige fra videresendt LAN-trafik, og mange værter begrænser ICMP. Hvis kravet er en privat tjeneste, så test den tjeneste på dens rigtige port.
Hold sondens volumen beskeden. En overvågningsløkke bør ikke blive den trafik, den måler.
Kontrol 4: hvad ændrede sig, og hvornår
Korrelér WAN-ændringer, nøglefornyelser, ruteudtræk og applikationsfejl på én tidslinje. Skeln en tunnelfejl fra en reserverute, der stille gendanner almindelig internetadgang, fordi de giver identiske brugerrapporter og modsatte diagnoser. Tidszonefejl vil vende rækkefølgen, så normalisér før sammenligning. Tidslinjen er det, der gør fire kontroller til en årsag.
Gem logfiler for overgangene, ikke for nyttelasten.
Kontrol 5: alarmen skal navngive grænsen
En alarm, der siger VPN nede, sender nogen det forkerte sted hen halvdelen af tiden. En, der siger peer-handshake forældet i tolv minutter, rute til 10.20.0.0/16 mangler, eller sonde til port 445 fejler, peger på en bestemt kontrol.
Hold driftstællere i stedet for at gennemse nyttelaster. Tællere besvarer overvågningsspørgsmålet uden at indsamle indhold, du ikke har brug for.
Og lad failover-politikken bestemme, hvad der sker derefter. Overvågning skal identificere, hvilken grænse der fejlede, ikke tillade en bred omgåelse, hver gang en sonde fejler. OpenVPN 2.6-manualen dokumenterer statusfilen og administrationsgrænsefladen, som gør den første kontrol scriptbar.