Din tunnel stod öppen hela natten, inget strömmades och användningsgrafen rörde sig ändå. Det är normalt: en VPN håller ett samtal öppet i stället för att reservera en del av din linje, så den reserverade andelen är noll medan byten är små och verkliga. De två begreppen byts ständigt ut, och därför besvaras frågan om en inaktiv VPN använder bandbredd dåligt i båda riktningarna. Att mäta rätt räknare över ett fönster du kan beskriva avgör saken på en eftermiddag.

Varför en inaktiv tunnel ändå flyttar byte

En tunnel är en mappning med en livstid, och något måste hålla den mappningen vid liv. Handskakningar löper ut, NAT-enheter släpper inaktiva översättningar, och en motpart som är tyst tillräckligt länge kan bli onåbar utan att något fallerar i någon ände. Protokollen skiljer sig i vad de skickar när det inte finns något att skicka: WireGuard överför ingenting som standard när handskakningen har satt sig, och den valfria PersistentKeepalive inställningen lägger till ett periodiskt paket så att en motpart bakom en översättning förblir nåbar. Slå på den med avsikt och intervallet blir synligt i en räknare.

OpenVPN har en keepalive-hjälpare som fungerar annorlunda: den definierar ping-liknande kontroller så att båda ändar kan skilja en levande session från en död, och klienter som har egen transport har motsvarande timers under andra namn. Inget av detta syns i ett programfönster, och därför säger en tom skärm ingenting om vad som finns på ledningen.

En inaktiv applikation är inte en inaktiv enhet

En öppen tunnel betjänar varje klient som är ansluten till den, och klienter slutar sällan. Bildsynk, resolver-frågor, uppdateringskontroller och en övervakningsagent följer den rutt som är standard, och på en full tunnelprofil är den rutten själva tunneln. En telefon som sover i fickan frågar ändå, och ett säkerhetskopieringsjobb bryr sig inte om att ingen tittar på en video. Tunneln är inaktiv i den meningen att du inte använder den medan dina enheter gör det.

Bryggade och routade profiler bär olika trafik, så samma observation kan ge olika svar på var och en. Skriv ned vem som var ansluten innan du mäter, för en enda synkklient kan väga tyngre än varje keepalive i intervallet.

Välj en räknare och säg vad den räknar

Det finns tre summor och var och en svarar på en annan fråga: vad som gick genom tunneln, vad som gick över den fysiska länken, och vad leverantören beslutade att fakturera. Att räkna på uplink räknar också allt som aldrig kom in i tunneln, från ARP-rörelser till grannens strömning. Att räkna på tunnelns gränssnitt missar den yttre headern, handskakningsförsöken och keepalives som håller en översättning öppen. Att läsa båda är billigt, och det är det enda sättet att se på vilken sida av tunneln en byte räknades.

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

Bestäm vilken av de två din fråga gäller innan du citerar någon av dem, för att addera dem räknar relaterat arbete två gånger. Leverantörens redovisning kan stängas i en senare period än den du mätte, så en summa som inte stämmer med fakturan är inte automatiskt fel. Fäst gränssnittet, riktningen och fönstret vid varje tal du publicerar.

Gör en kort övervakad mätning

Låt tunneln och dess skydd vara exakt som de kör en vanlig dag, hoppa över valfria överföringar och notera vem som blev kvar ansluten. Läs räknarna, vänta ett fönster som är långt nog att vara värt att läsa, läs dem igen och håll den förflutna tiden bredvid skillnaden. Ett stort hastighetstest svarar på en annan fråga: det mättar länken och säger ingenting om kostnaden för inaktivitet.

Upprepa fönstret en gång om det första resultatet verkar omöjligt, för ett enda prov kan fånga ett schemalagt jobb mitt i. Två intervall som stämmer är bevis; ett intervall är en anekdot med enheter.

Köp inte en renare nolla med en sämre tunnel

Att stänga av en keepalive eller en livskontroll för att städa grafen ändrar den distribution du mäter, och tunneln kanske inte kommer tillbaka efter nästa inaktiva period. Fråga om mekanismen tjänar nåbarhet eller underhåll innan du rör den, och mät med den på om den gör det, eftersom det är konfigurationen du kommer att stödja. En renare nolla som döljer en trasig återhämtningsväg är det dyraste resultatet i den här övningen.

När talet verkligen är stort, hitta processen eller klienten som producerade det i stället för att anta att protokollet fyller linjen. Jämför den inre och den yttre räknaren för att se vilken sida byten finns på, och rapportera sedan användning för den perioden i stället för kapacitet du tror du äger.

Relaterade artiklar