Formning av OpenVPN-trafik: vilket gränssnitt ser den?

Gå igenom fyra kontroller: vad du vill begränsa, vilket paket som bär informationen som identifierar det, vilket gränssnitt formaren kan se och vad routern klarar medan den krypterar. Routrar levereras med både en OpenVPN-sida och en bandbreddssida, och att båda finns bevisar ingenting om någon av dem. Ordningen spelar roll, eftersom en regel skriven mot fel paket aldrig matchar, hur korrekt dess hastighet än är.

Börja med målet: begränsa en enskild enhet, dela kapaciteten rättvist eller prioritera en applikation. Var och en behöver en annan matchning.

Namnge målet före regeln

En gräns per enhet behöver en matchning på den enhetens adress, som bara finns inne i tunneln. Rättvisa mellan konkurrerande flöden behöver en kö som alla delar, inte en regel per värd. Applikationsprioritet behöver något som identifierar applikationen, det svåraste av de tre när krypteringen tar bort inre huvuden från synfältet. Att skriva ned målet först talar om vilket faktum du behöver och var du möjligen kan få det.

En gräns som fungerar på direkt WAN-trafik är inget bevis för att samma värd täcks inne i tunneln. Regeln kan matcha en adress som aldrig förekommer i det huvud formaren ser.

Inne i tunneln eller utanför den

Med en routerägd VPN-klient färdas många LAN-flöden inuti en enda krypterad transport. Före inkapslingen ser routern fortfarande den inre källan och destinationen, så policy som kopplas vid det steget kan klassificera per enhet. Efter inkapslingen ser vanlig utrustning bara den yttre anslutningen, och en matchning på VPN-porten säger ingenting om vilken enhet som är ansvarig. Det enda faktumet avgör var regeln hör hemma.

Plattformar skiljer sig i hur de exponerar detta. Vissa tillhandahåller en formare som köar och klassificerar på ett tunnelgränssnitt; andra behandlar begränsare som gränssnittsregler som beter sig likadant för VPN- och icke-VPN-trafik; somliga gör båda med olika förmågor. Läs firmwarens egen dokumentation för det gränssnitt den stöder i stället för att kopiera ett gränssnittsnamn från en annan tillverkares guide.

Identifiera var adresser fortfarande är tillgängliga, var översättning sker och vilken kö som faktiskt styr flaskhalsen.

Tre policyer, tre slags bevis

En hastighetsgräns bevisas av en uthållig överföring från den begränsade enheten medan en annan överför samtidigt. Rättvis delning bevisas av två flöden som når liknande hastigheter i stället för att ett svälter, vilket är en annan mätning. Applikationsprioritet bevisas av en interaktiv uppgift som förblir responsiv under en bulköverföring, och genom att kontrollera att klassificeraren alls kände igen flödet. Varje policy behöver sin egen observation, och ingen bevisas av en konfigurationssida.

Klassificering förtjänar särskild misstänksamhet. En matchning på yttre krypterad port kan inte återvinna varje inre applikations identitet, så en regel som verkar prioritera en applikation kan i praktiken prioritera allt från den tunneln. Läs regelns räknare i stället för dess avsikt.

Mät den krypterade arbetslasten, inte den nakna

Formning, klassificering och kryptering konkurrerar om en CPU, och hårdvaruacceleration kan flytta trafik förbi just de regler och räknare du tittar på. En genomströmningssiffra från ett vanligt routingtest säger lite om lådan under en krypterad och formad arbetslast. Testa båda riktningarna, flera representativa klienter och en liten interaktiv uppgift vid sidan av bulköverföringen. Responsivitet under last är viktigare än toppsiffran på en ledig länk.

Ta med undantagen i mätningen: trafik som ska gå förbi tunneln, båda adressfamiljerna om båda är i spel, och vad som händer när tunneln är nere. En policy som beter sig förnuftigt bara medan tunneln är frisk är en halv policy.

Skriv specifikationen som tre rader: trafikmatchningen, tillämpningspunkten och den uppmätta arbetslasten. OpenVPN plus QoS är ingen specifikation.