Een router-VPN bewaken zonder op één statuslampje te vertrouwen
Peerstatus, de gekozen route en een toegestane applicatietest beantwoorden verschillende vragen. Alarmeer op de grens die faalde, niet op een groen pictogram.
De statuspagina zegt verbonden, het lampje is groen en het kantoor bereikt de fileserver niet. Een van die feiten gaat over de tunnel, het andere over de weg erdoorheen. Beide bewaken is het verschil tussen een melding waarop u kunt reageren en een die u leert negeren.
Vijf controles, op volgorde, van de peer naar buiten.
Controle 1: peer- of associatiestatus
Elk protocol toont zijn eigen status. WireGuard toont de laatste handshake en overdrachtstellers per peer via wg show. OpenVPN schrijft sessiestatus naar zijn statusbestand of beheerinterface, en IPsec toont beveiligingsassociaties via hulpprogramma's zoals ipsec statusall. De valkuil is een tijdstempel als vonnis te lezen: een inactieve WireGuard-peer zonder iets te verzenden doet niet recent een handshake, en dat is geen storing.
Vergelijk de tijdstempel met verwacht verkeer en keepalive-instellingen voordat u iemand oproept.
Controle 2: de gekozen route
Een tunnelinterface kan bestaan terwijl er niets naartoe wordt gerouteerd. Controleer de doorstuurtabel voor de bestemming die u aangaat, niet voor het eigen subnet van de tunnel. Ontbreekt het prefix of wijst het elders heen, dan is de peerstatus irrelevant.
Die controle vangt de fout die een statuslampje nooit toont.
Een nuttige tweede controle vergelijkt ook het bronadres. ip route get 10.20.5.10 geeft de volgende hop, de interface en de voorkeursbron terug, en een verkeerde bron is genoeg om retourverkeer aan de andere kant te breken. Noteer het verwachte drietal één keer en alarmeer daarna wanneer een element verandert. Die ene regel vangt NAT-wijzigingen, interface-flaps en fouten in op beleid gebaseerde routering.
Controle 3: een toegestaan applicatiepad
Test iets dat representatief is voor de werkelijke eis. Een ping vanaf de router vertrekt vanaf het eigen adres en beleid van de router, die kunnen afwijken van doorgegeven LAN-verkeer, en veel hosts beperken ICMP. Is de eis een privédienst, test die dienst dan op zijn echte poort.
Houd het testvolume bescheiden. Een bewakingslus moet niet het verkeer worden dat hij meet.
Controle 4: wat veranderde en wanneer
Correleer WAN-wijzigingen, sleutelvernieuwingen, route-intrekkingen en applicatiefouten op één tijdlijn. Onderscheid een tunnelstoring van een fallbackroute die stilzwijgend normale internettoegang herstelt, want die geven identieke gebruikersmeldingen en tegengestelde diagnoses. Tijdzonefouten keren de volgorde om, dus normaliseer voordat u vergelijkt. De tijdlijn is wat vier controles in een oorzaak verandert.
Bewaar logboeken voor de overgangen, niet voor de payload.
Controle 5: het alarm moet de grens noemen
Een alarm dat VPN down zegt, stuurt iemand de helft van de tijd naar de verkeerde plek. Een dat zegt dat de peer-handshake twaalf minuten oud is, de route naar 10.20.0.0/16 ontbreekt of de test naar poort 445 mislukt, wijst naar een specifieke controle.
Houd operationele tellers bij in plaats van payloads te doorzoeken. Tellers beantwoorden de bewakingsvraag zonder inhoud te verzamelen die u niet nodig hebt.
En laat het failoverbeleid beslissen wat er daarna gebeurt. Bewaking moet vaststellen welke grens faalde, niet elke keer een brede omleiding toestaan wanneer een test mislukt. De OpenVPN 2.6-handleiding documenteert het statusbestand en de beheerinterface die de eerste controle scriptbaar maken.