Hoe u controleert of een Linux-VPN-tunnel echt actief is

Cron herstart elke tien minuten een volkomen gezonde VPN, en dezelfde taak laat een dode een week lang draaien. Beide fouten komen ervan dat «actief» als één feit wordt behandeld terwijl het er minstens vier zijn. Een apparaat kan administratief ingeschakeld, correct gerouteerd, volledig versleuteld zijn en toch niets bruikbaars vervoeren. Scheid eerst de waarnemingen, en de controle schrijft zich bijna zelf.

Linkflags beschrijven het apparaat, niet het pad

De controle die iedereen kopieert zoekt een hardwareadres van louter nullen. Die truc scheidt in sommige stuurprogramma's een echte interface van een plaatshouder en bewijst in de rest niets, omdat een tun-apparaat helemaal geen MAC heeft om te melden. ip -brief link show tun0 geeft in plaats daarvan flags: UP betekent dat een beheerder het apparaat heeft ingeschakeld, en LOWER_UP betekent dat het stuurprogramma de link bruikbaar acht. Samen gelezen zeggen ze dat het apparaat bestaat en niet administratief uit staat. Geen van beide zegt dat een pakket ergens heen kan.

OpenVPN maakt zijn tun-apparaat aan voordat routes worden geïnstalleerd, dus de flags kunnen perfect lijken terwijl niets is gerouteerd. Behandel ze als een voorwaarde, nooit als het antwoord.

Vraag waar een pakket heen zou gaan

De routeopzoeking beantwoordt de vraag die de flags niet kunnen. ip route get 10.8.0.1 from 10.8.0.2 noemt de interface, het bronadres en de tabel die de kernel zou gebruiken, en dat is precies waar een gesplitste tunnel tegen moet worden gecontroleerd. Zonder bronadres vraagt u iets anders, en met beleidsroutering kan het antwoord per bron verschillen. Dit is de goedkoopste eerlijke test, omdat hij dezelfde regels raadpleegt als uw verkeer.

Voeg voor WireGuard de handshake toe. wg show drukt per peer een tijdstempel van de laatste handshake af, en een tijdstempel die niet meer vooruitgaat betekent dat de peer weg is, wat de interfaceflags ook zeggen. Een geconfigureerde interface zonder recente handshake is een van de vaakste valse positieven in zelfgebouwde monitoring.

Tabel 220 vertelt het verhaal van IPsec

strongSwan installeert routes voor onderhandelde selectors in tabel 220 wanneer route-installatie is ingeschakeld. ip route list table 220 scheidt daardoor onderhandeld van gerouteerd: een lege tabel naast een geladen verbinding betekent dat de IKE- en CHILD-SA's omhoog kwamen terwijl er geen verkeer naar binnen wordt geleid. Controleer ip xfrm state ernaast, want die somt de geïnstalleerde beveiligingsassociaties en hun eindpunten op.

Een valstrikbeleid is het geval waarop u moet letten. Het wacht op interessant verkeer in plaats van het te routeren, dus de tabel blijft leeg tot iets de tunnel activeert.

Beheerderstoestand en daemontoestand zijn verschillende lijsten

NetworkManager somt alleen de verbindingen op die het bezit. nmcli -t -f NAME,TYPE connection show --active geeft niets terug voor een tunnel die rechtstreeks is gestart door wg-quick of door een OpenVPN-daemon.

Dat onderscheid is van belang wanneer een script moet beslissen welke van twee beheerders het vraagt. Kies degene die de tunnel op deze host werkelijk bezit en negeer de stilte van de ander. Als beide bestaan, bepaal welke gezaghebbend is en schakel de tweede uit, want twee beheerders die op één interface routes herschrijven produceren fouten die niemand kan reproduceren. Een ontbrekende vermelding is informatie over de beheerder, niet over de tunnel.

Maak de volgende stap afhankelijk van de controle die hij nodig heeft

Een UDP-poort pollen bewijst niets over gereedheid, want UDP heeft geen handshake en nc -u slaagt zodra het pakket vertrekt. Controleer wat de volgende stap werkelijk verbruikt: een TCP-verbinding naar de doorgestuurde poort, een verzoek aan een host binnen de tunnel, een naam die alleen daar wordt opgelost. Begrens het wachten met een time-out en een aantal pogingen, en faal luid wanneer het op is.

Hooks verslaan polling wanneer de client ze biedt. --up en --down scripts van OpenVPN draaien nadat de interface van toestand verandert, wat de race volledig wegneemt, maar ze draaien met de rechten die de daemon heeft behouden. Als OpenVPN via user en group naar een onbevoorrecht account is gezakt, draait de hook als dat account. Een systeemdienst herstarten vereist dan sudo om precies die opdracht toe te staan. Geef de herhaling aan de dienstbeheerder in plaats van aan een cron-lus: een begrensd herstartbeleid met een startlimiet maakt een kapotte tunnel zichtbaar, terwijl een onbegrensde lus hem onbeperkt verbergt.