Tunnelen din sto åpen hele natten, ingenting ble strømmet, og bruksgrafen beveget seg likevel. Det er normalt: en VPN holder en samtale åpen i stedet for å reservere en del av linjen din, så den reserverte andelen er null mens bytene er små og ekte. De to begrepene byttes stadig om, og derfor besvares spørsmålet om en inaktiv VPN bruker båndbredde dårlig i begge retninger. Å måle den riktige telleren over et tidsvindu du kan beskrive avgjør saken på en ettermiddag.

Hvorfor en inaktiv tunnel likevel flytter bytes

En tunnel er en mapping med en levetid, og noe må holde den mappingen i live. Håndtrykk utløper, NAT-enheter slipper inaktive oversettelser, og en motpart som er stille lenge nok kan bli utilgjengelig uten at noe feiler i noen ende. Protokollene er forskjellige i hva de sender når det ikke er noe å sende: WireGuard overfører ingenting som standard når håndtrykket har satt seg, og den valgfrie PersistentKeepalive innstillingen legger til en periodisk pakke slik at en motpart bak en oversettelse forblir tilgjengelig. Slå den på med vilje, og intervallet blir synlig i en teller.

OpenVPN har en keepalive-hjelper som virker annerledes: den definerer ping-lignende kontroller slik at begge ender kan skille en levende økt fra en død, og klienter som har sin egen transport har tilsvarende timere under andre navn. Ingenting av dette vises i et applikasjonsvindu, og derfor sier en tom skjerm ingenting om hva som er på linjen.

En inaktiv applikasjon er ikke en inaktiv enhet

En åpen tunnel betjener hver klient som er koblet til den, og klientene stopper sjelden. Bildesynkronisering, resolver-spørringer, oppdateringssjekker og en overvåkingsagent følger den ruten som er standard, og på en full tunnelprofil er den ruten selve tunnelen. En telefon som sover i lommen spør likevel, og en sikkerhetskopijobb bryr seg ikke om at ingen ser på en video. Tunnelen er inaktiv i den forstand at du ikke bruker den mens enhetene dine gjør det.

Brodd og rutede profiler bærer ulik trafikk, så samme observasjon kan gi ulikt svar på hver av dem. Skriv ned hvem som var tilkoblet før du måler, fordi én synkroniseringsklient kan veie mer enn hver keepalive i intervallet.

Velg én teller og si hva den teller

Det finnes tre totaler, og hver svarer på et ulikt spørsmål: hva som gikk gjennom tunnelen, hva som gikk over den fysiske linken, og hva leverandøren bestemte seg for å fakturere. Å telle på uplink teller også alt som aldri kom inn i tunnelen, fra ARP-bevegelse til naboens strømming. Å telle på tunnelgrensesnittet mister den ytre headeren, håndtrykksforsøkene og keepalivene som holder en oversettelse åpen. Å lese begge er billig, og det er den eneste måten å se på hvilken side av tunnelen en byte ble telt.

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

Avgjør hvilken av de to spørsmålet ditt gjelder før du oppgir noen av dem, fordi å legge dem sammen teller relatert arbeid to ganger. Leverandørens regnskap kan lukkes i en senere periode enn den du målte, så en total som ikke stemmer med fakturaen er ikke automatisk feil. Fest grensesnittet, retningen og tidsvinduet til hvert tall du publiserer.

Kjør en kort overvåket måling

La tunnelen og beskyttelsen være nøyaktig slik de kjører en vanlig dag, hopp over valgfrie overføringer, og noter hvem som ble værende tilkoblet. Les tellerne, vent et tidsvindu som er langt nok til å være verdt å lese, les dem igjen, og hold den medgåtte tiden ved siden av differansen. En stor hastighetstest svarer på et annet spørsmål: den metter linken og sier ingenting om inaktiv kostnad.

Gjenta vinduet én gang hvis det første resultatet virker umulig, fordi én prøve kan fange en planlagt jobb midt i. To intervaller som stemmer er bevis; ett intervall er en anekdote med enheter.

Ikke kjøp en renere null med en dårligere tunnel

Å slå av en keepalive eller en livssjekk for å rydde i grafen endrer utplasseringen du måler, og tunnelen kan kanskje ikke komme tilbake etter neste inaktive periode. Spør om mekanismen tjener tilgjengelighet eller vedlikehold før du rører den, og mål med den på hvis den gjør det, siden det er konfigurasjonen du skal støtte. En renere null som skjuler en ødelagt gjenopprettingsvei er det dyreste resultatet i denne øvelsen.

Når tallet virkelig er stort, finn prosessen eller klienten som produserte det i stedet for å anta at protokollen fyller linjen. Sammenlign den indre og den ytre telleren for å se hvilken side bytene er på, og rapporter deretter bruk for den perioden i stedet for kapasitet du tror du eier.

Relaterte artikler