Din tunnel har været åben hele natten, intet er blevet streamet, og alligevel har brugsgrafen flyttet sig. Det er normalt: en VPN holder en samtale åben i stedet for at reservere en del af din linje, så den reserverede andel er nul, mens byte er små og reelle. De to opfattelser bliver konstant byttet om, og derfor besvares spørgsmålet "bruger en inaktiv VPN båndbredde" dårligt i begge retninger. At måle den rigtige tæller over et vindue, du kan beskrive, afgør sagen på en eftermiddag.

Hvorfor en inaktiv tunnel stadig flytter byte

En tunnel er en mapping med en levetid, og noget skal holde den mapping levende. Håndtryk udløber, NAT-enheder smider inaktive oversættelser væk, og en peer, der tier stille længe nok, kan blive utilgængelig, uden at noget svigter i nogen ende. Protokoller er forskellige i, hvad de sender, når der ikke er noget at sende: WireGuard transmitterer intet som standard, når håndtrykket har sat sig, og den valgfri PersistentKeepalive indstilling tilføjer en periodisk pakke, så en peer bag en oversættelse forbliver tilgængelig. Slå den bevidst til, og intervallet bliver synligt i en tæller.

OpenVPN — dens keepalive-hjælper virker anderledes: den definerer kontrol i stil med kald, så begge ender kan skelne en levende session fra en død, og klienter, der bringer deres egen transport, har tilsvarende timere under andre navne. Intet af dette vises i et programvindue, og derfor siger en tom skærm intet om, hvad der er på ledningen.

En inaktiv applikation er ikke en inaktiv enhed

En åben tunnel betjener hver klient, der er knyttet til den, og klienter stopper sjældent. Fotopublicering, resolver-forespørgsler, opdateringstjek og en overvågningsagent følger den rute, der nu er standard, og på en fuld tunnel-profil er den rute tunnelen. En telefon, der sover i en lomme, spørger stadig, og en backup-opgave er ligeglad med, at ingen ser en video. Tunnelen er inaktiv i den forstand, at du ikke bruger den, mens dine enheder gør.

Bro- og rutede profiler bærer forskellig trafik, så samme observation kan give et forskelligt svar på hver. Skriv ned, hvem der var forbundet, før du måler, fordi én synkroniseringsklient kan opveje enhver keepalive i intervallet.

Vælg én tæller, og sig, hvad den tæller

Der findes tre totaler, og hver besvarer et forskelligt spørgsmål: hvad der gik gennem tunnelen, hvad der gik over det fysiske link, og hvad udbyderen besluttede at fakturere. At tælle på uplink tæller også alt, der aldrig kom ind i tunnelen, fra ARP-bevægelser til naboens streaming. At tælle på tunnelens interface misser den ydre header, håndtryksforsøgene og de keepalives, der holder en oversættelse åben. At læse begge er billigt, og det er den eneste måde at se, på hvilken side af tunnelen en byte blev talt.

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

Beslut, hvilken af de to dine spørgsmål handler om, før du citerer nogen af dem, fordi at lægge dem sammen tæller relateret arbejde to gange. Udbyderens bogføring kan lukke i en senere periode end den, du målte, så en total, der ikke stemmer med fakturaen, er ikke automatisk forkert. Vedhæft interfacet, retningen og vinduet til det tal, du offentliggør.

Lav en kort måling under opsyn

Lad tunnelen og dens beskyttelse køre præcis som på en normal dag, spring valgfri overførsler over, og noter, hvem der blev forbundet. Læs tællerne, vent et vindue, der er langt nok til at være værd at læse, læs dem igen, og hold den forløbne tid ved siden af forskellen. En stor hastighedstest besvarer et andet spørgsmål: den mætter linket og siger intet om inaktivitetens pris.

Gentag vinduet én gang, hvis det første resultat ser umuligt ud, fordi en enkelt prøve kan fange en planlagt opgave midt i arbejdet. To intervaller, der stemmer, er bevis; ét interval er en anekdote med enheder.

Køb ikke et renere nul med en dårligere tunnel

At slå en keepalive eller livstjek fra for at rydde op i grafen ændrer den udrulning, du måler, og tunnelen kommer måske ikke tilbage efter den næste inaktive periode. Spørg, om mekanismen tjener tilgængelighed eller vedligeholdelse, før du rører ved den, og mål med den kørende, hvis den gør, for det er den konfiguration, du skal understøtte. Et renere nul, der skjuler en brudt gendannelsesvej, er det dyreste resultat i denne øvelse.

Når tallet er virkelig stort, find den proces eller klient, der skabte det, i stedet for at antage, at protokollen fylder linjen. Sammenlign de indre og ydre tællere for at se, på hvilken side byte er, og rapportér derefter forbrug for den periode i stedet for kapacitet, som du tror, du ejer.

Relaterede artikler