Forming av OpenVPN-trafikk: hvilket grensesnitt ser den?

Gå gjennom fire kontroller: hva du vil begrense, hvilken pakke som bærer informasjonen som identifiserer det, hvilket grensesnitt formatteren kan se, og hva ruteren tåler mens den krypterer. Rutere leveres både med en OpenVPN-side og en båndbreddeside, og deres sameksistens beviser ingenting om noen av dem. Rekkefølgen betyr noe, fordi en regel skrevet mot feil pakke aldri treffer, uansett hvor riktig hastigheten er.

Start med målet: begrense én enhet, dele kapasiteten rettferdig eller prioritere én applikasjon. Hver krever en annen match.

Navngi målet før regelen

En grense per enhet krever en match på den enhetens adresse, som bare finnes inne i tunnelen. Rettferdighet mellom konkurrerende strømmer krever en kø de alle deler, ikke en regel per vert. Applikasjonsprioritet krever noe som identifiserer applikasjonen, det vanskeligste av de tre når krypteringen fjerner de indre hodene fra syne. Å skrive målet først forteller deg hvilket faktum du trenger og hvor du muligens kan få det.

En grense som virker på direkte WAN-trafikk er ikke bevis for at samme vert er dekket inne i tunnelen. Regelen matcher kanskje en adresse som aldri dukker opp i hodet formatteren ser.

Inne i tunnelen eller utenfor

Med en VPN-klient som ruteren eier, reiser mange LAN-strømmer inne i én kryptert transport. Før innkapslingen ser ruteren fortsatt den indre kilden og destinasjonen, så policy festet på det trinnet kan klassifisere per enhet. Etter innkapslingen ser vanlig utstyr bare den ytre forbindelsen, og en match på VPN-porten sier ingenting om hvilken enhet som er ansvarlig. Det ene faktumet avgjør hvor regelen hører hjemme.

Plattformer er forskjellige i hvordan de viser dette. Noen tilbyr en formatter som køer og klassifiserer på et tunellgrensesnitt; andre behandler begrensere som grensesnittregler som oppfører seg likt for VPN- og ikke-VPN-trafikk; noen gjør begge med ulike evner. Les fastvarens egen dokumentasjon for grensesnittet den støtter, i stedet for å kopiere et grensesnittnavn fra en annen leverandørs veiledning.

Identifiser hvor adresser forblir tilgjengelige, hvor oversettelsen skjer og hvilken kø som faktisk kontrollerer flaskehalsen.

Tre policyer, tre slags bevis

En hastighetsgrense bevises av en vedvarende overføring fra den begrensede enheten mens en annen overfører samtidig. Rettferdig deling bevises av to strømmer som når lignende hastigheter i stedet for at én sulter, noe som er en annen måling. Applikasjonsprioritet bevises av at en interaktiv oppgave forblir responsiv under en stor overføring, og ved å sjekke at klassifisereren i det hele tatt gjenkjente strømmen. Hver policy krever sin egen observasjon, og ingen bevises av en konfigurasjonsside.

Klassifisering fortjener spesiell mistanke. En match på den ytre krypterte porten kan ikke gjenopprette identiteten til hver indre applikasjon, så en regel som ser ut til å prioritere én applikasjon kan i praksis prioritere alt fra den tunnelen. Les reglens tellere i stedet for hensikten.

Mål den krypterte belastningen, ikke den bare

Forming, klassifisering og kryptering konkurrerer om én CPU, og maskinvareakselerasjon kan føre trafikk forbi nettopp de reglene og tellerne du overvåker. Et gjennomstrømningstall fra en vanlig rutertest sier lite om boksen under en kryptert og formet belastning. Test begge retninger, flere representative klienter og en liten interaktiv oppgave ved siden av den store overføringen. Responsivitet under belastning betyr mer enn topptall på en ledig linje.

Ta med unntakene i målingen: trafikk som skal omgå tunnelen, begge adressefamiliene hvis begge er i spill, og hva som skjer når tunnelen er nede. En policy som bare oppfører seg fornuftig mens tunnelen er sunn, er en halv policy.

Skriv spesifikasjonen som tre linjer: trafikkmatchen, håndhevelsespunktet og den målte belastningen. OpenVPN pluss QoS er ikke en spesifikasjon.