Verbruikt een inactieve VPN bandbreedte? Lees de juiste teller

Je tunnel stond de hele nacht open, er werd niets gestreamd en toch bewoog de gebruiksgraaf. Dat is normaal: een VPN houdt een gesprek open in plaats van een deel van je lijn te reserveren, dus het gereserveerde deel is nul terwijl de bytes klein en echt zijn. De twee ideeën worden voortdurend verwisseld, en daarom wordt de vraag of een inactieve VPN bandbreedte gebruikt in beide richtingen slecht beantwoord. De juiste teller meten over een venster dat je kunt beschrijven beslecht het in één middag.

Waarom een inactieve tunnel toch bytes verplaatst

Een tunnel is een mapping met een levensduur, en iets moet die mapping in leven houden. Handshakes verlopen, NAT-apparaten laten inactieve vertalingen vallen, en een peer die lang genoeg stil blijft kan onbereikbaar worden zonder dat er aan beide kanten iets faalt. Protocollen verschillen in wat ze sturen als er niets te sturen is: WireGuard verzendt standaard niets zodra de handshake zich heeft gezet, en de optionele PersistentKeepalive instelling voegt een periodiek pakket toe zodat een peer achter een vertaling bereikbaar blijft. Zet hem bewust aan en het interval wordt zichtbaar in een teller.

OpenVPN heeft een keepalive-helper die anders werkt: hij definieert ping-achtige controles zodat beide uiteinden een levende sessie van een dode kunnen onderscheiden, en clients die hun eigen transport meebrengen hebben gelijkwaardige timers onder andere namen. Niets hiervan verschijnt in een toepassingsvenster, en daarom zegt een leeg scherm niets over wat er op de lijn zit.

Een inactieve toepassing is geen inactief apparaat

Een open tunnel bedient elke client die eraan is gekoppeld, en clients stoppen zelden. Fotósynchronisatie, resolver-query's, updatecontroles en een monitoringsagent volgen de route die standaard is, en op een volledig tunnelprofiel is die route de tunnel zelf. Een telefoon die in een zak slaapt, peilt nog steeds, en een back-uptaak kan het niet schelen dat niemand naar een video kijkt. De tunnel is inactief in de zin dat jij hem niet gebruikt terwijl je apparaten dat wel doen.

Bridged en gerouteerde profielen dragen verschillend verkeer, dus dezelfde waarneming kan op elk daarvan een ander antwoord opleveren. Schrijf op wie er verbonden was voordat je meet, want één synchronisatieclient kan zwaarder wegen dan elke keepalive in het interval.

Kies één teller en zeg wat hij telt

Er bestaan drie totalen en elk beantwoordt een andere vraag: wat de tunnel passeerde, wat de fysieke link passeerde, en wat de provider besloot te factureren. Tellen op de uplink telt ook alles wat nooit in de tunnel kwam, van ARP-beweging tot de streaming van de buurman. Tellen op de tunnelinterface mist de buitenste header, de handshake-pogingen en de keepalives die een vertaling openhouden. Beide lezen is goedkoop, en het is de enige manier om te zien aan welke kant van de tunnel een byte is geteld.

ip -s link show wg0
ip -s link show eth0

Bepaal op welke van de twee je vraag betrekking heeft voordat je een van beide noemt, want ze optellen telt verwant werk dubbel. De administratie van de provider kan in een latere periode sluiten dan degene die je hebt gemeten, dus een totaal dat niet met de factuur overeenkomt is niet automatisch fout. Hang de interface, de richting en het venster aan elk getal dat je publiceert.

Voer een korte begeleide meting uit

Laat de tunnel en zijn bescherming precies zoals ze op een normale dag draaien, sla optionele overdrachten over en noteer wie verbonden bleef. Lees de tellers, wacht een venster dat lang genoeg is om de moeite waard te zijn, lees ze opnieuw en houd de verstreken tijd naast het verschil. Een grote snelheidstest beantwoordt een andere vraag: hij verzadigt de link en zegt niets over de kosten van inactiviteit.

Herhaal het venster één keer als het eerste resultaat onmogelijk lijkt, want één monster kan een geplande taak midden in het proces vangen. Twee intervallen die overeenkomen zijn bewijs; één interval is een anekdote met eenheden.

Koop geen schonere nul met een slechtere tunnel

Een keepalive of een levenscheck uitzetten om de graaf op te ruimen verandert de uitrol die je meet, en de tunnel komt na de volgende inactieve periode misschien niet terug. Vraag of het mechanisme bereikbaarheid of onderhoud dient voordat je het aanraakt, en meet met het aan als dat zo is, want dat is de configuratie die je gaat ondersteunen. Een schonere nul die een kapotte herstelroute verbergt is het duurste resultaat in deze oefening.

Als het getal echt groot is, zoek dan het proces of de client dat het heeft geproduceerd in plaats van aan te nemen dat het protocol de lijn vult. Vergelijk de binnenste en buitenste teller om te zien aan welke kant de bytes zitten, en rapporteer vervolgens het gebruik voor die periode in plaats van capaciteit waarvan je denkt dat je die bezit.