Formning af OpenVPN-trafik: hvilken grænseflade ser den?

Gå gennem fire kontroller: hvad du vil begrænse, hvilken pakke der bærer de oplysninger, der identificerer det, hvilken grænseflade formeren kan se, og hvad routeren kan klare, mens den krypterer. Routere leveres både med en OpenVPN-side og en båndbreddeside, og deres sameksistens beviser intet om nogen af dem. Rækkefølgen betyder noget, fordi en regel skrevet mod den forkerte pakke aldrig matcher, hvor korrekt dens hastighed end er.

Start med målet: begræns en enkelt enhed, del kapaciteten retfærdigt, eller prioriter en enkelt applikation. Hver især kræver et forskelligt match.

Navngiv målet før reglen

Et loft per enhed kræver et match på den enheds adresse, som kun findes inde i tunnelen. Retfærdighed mellem konkurrerende strømme kræver en kø, som de alle deler, ikke en regel per vært. Applikationsprioritet kræver noget, der identificerer applikationen, det sværeste af de tre, når krypteringen fjerner de indre headers fra syne. At skrive målet ned først fortæller dig, hvilket faktum du har brug for, og hvor du muligvis kan skaffe det.

Et loft, der virker på direkte WAN-trafik, er intet bevis for, at den samme vært er dækket inde i tunnelen. Reglen matcher måske en adresse, der aldrig optræder i den header, formeren ser.

Inde i tunnelen eller uden for den

Med en VPN-klient, som routeren ejer, rejser mange LAN-strømme inde i én krypteret transport. Før indkapslingen ser routeren stadig den indre kilde og destination, så politik knyttet til det trin kan klassificere per enhed. Efter indkapslingen ser almindeligt udstyr kun den ydre forbindelse, og et match på VPN-porten siger intet om, hvilken enhed der er ansvarlig. Den ene kendsgerning afgør, hvor reglen hører til.

Platforme er forskellige i, hvordan de viser dette. Nogle tilbyder en former, der sætter i kø og klassificerer på en tunnelgrænseflade; andre behandler begrænsere som grænsefladeregler, der opfører sig ens for VPN- og ikke-VPN-trafik; nogle gør begge dele med forskellige evner. Læs firmwarens egen dokumentation for den grænseflade, den understøtter, i stedet for at kopiere et grænsefladenavn fra en anden leverandørs vejledning.

Identificér, hvor adresser forbliver tilgængelige, hvor oversættelsen sker, og hvilken kø der faktisk styrer flaskehalsen.

Tre politikker, tre slags beviser

Et hastighedsloft bevises ved en vedvarende overførsel fra den begrænsede enhed, mens en anden overfører samtidig. Retfærdig deling bevises ved to strømme, der når lignende hastigheder i stedet for at en sulter, hvilket er en anden måling. Applikationsprioritet bevises ved, at en interaktiv opgave forbliver lydhør under en stor overførsel, og ved at kontrollere, at klassificeringen overhovedet genkendte strømmen. Hver politik kræver sin egen observation, og ingen bevises af en konfigurationsside.

Klassificering fortjener særlig mistanke. Et match på den ydre krypterede port kan ikke genskabe identiteten af hver indre applikation, så en regel, der ser ud til at prioritere én applikation, kan i praksis prioritere alt fra den tunnel. Læs reglens tællere i stedet for dens hensigt.

Mål den krypterede belastning, ikke den bare

Formning, klassificering og kryptering konkurrerer om én CPU, og hardwareacceleration kan føre trafik forbi netop de regler og tællere, du overvåger. Et gennemstrømningstal fra en almindelig routingtest siger lidt om boksen under en krypteret og formet belastning. Test begge retninger, flere repræsentative klienter og en lille interaktiv opgave ved siden af den store overførsel. Lydhørhed under belastning betyder mere end spidstallet på et ledigt link.

Medtag undtagelserne i målingen: trafik, der bør omgå tunnelen, begge adressefamilier, hvis begge er i spil, og hvad der sker, når tunnelen er nede. En politik, der kun opfører sig fornuftigt, mens tunnelen er sund, er en halv politik.

Skriv specifikationen som tre linjer: trafikmatchet, håndhævelsespunktet og den målte belastning. OpenVPN plus QoS er ikke en specifikation.