Forming av OpenVPN-trafikk: kva grensesnitt ser han?

Gå gjennom fire kontrollar: kva du vil avgrense, kva pakke som ber informasjonen som identifiserer det, kva grensesnitt formatøren kan sjå, og kva rutaren toler medan han krypterer. Rutarar blir leverte både med ei OpenVPN-side og ei bandbreiddside, og samveret deira beviser ingenting om nokon av dei. Rekkjefølgja har noko å seie, fordi ei regel skriven mot feil pakke aldri treff, uansett kor riktig farten er.

Byrja med målet: avgrense éin eining, dele kapasiteten rettferdig eller prioritere éin applikasjon. Kvar krev ein annan match.

Namngje målet før regelen

Ei grense per eining krev ein match på adressa til den eininga, som berre finst inne i tunnelen. Rettferd mellom konkurrerande straumar krev ein kø dei alle deler, ikkje ei regel per vert. Applikasjonsprioritet krev noko som identifiserer applikasjonen, det vanskelegaste av dei tre når krypteringa fjernar dei indre hovuda frå syne. Å skrive målet først fortel deg kva faktum du treng og kvar du moglegvis kan få det.

Ei grense som verkar på direkte WAN-trafikk er ikkje bevis for at same vert er dekt inne i tunnelen. Regelen matchar kanskje ei adresse som aldri dukkar opp i hovudet formatøren ser.

Inne i tunnelen eller utanfor

Med ein VPN-klient som rutaren eig, reiser mange LAN-straumar inne i éin kryptert transport. Før innkapslinga ser rutaren framleis den indre kjelda og destinasjonen, så policy festa på det trinnet kan klassifisere per eining. Etter innkapslinga ser vanleg utstyr berre den ytre sambindinga, og ein match på VPN-porten seier ingenting om kva eining som er ansvarleg. Det eine faktumet avgjer kvar regelen høyrer heime.

Plattformar er ulike i korleis dei viser dette. Nokre tilbyr ein formatør som køar og klassifiserer på eit tunellgrensesnitt; andre handsamar avgrensarar som grensesnittreglar som oppfører seg likt for VPN- og ikkje-VPN-trafikk; nokre gjer begge med ulike evner. Les fastvarens eiga dokumentasjon for grensesnittet han støttar, i staden for å kopiere eit grensesnittnamn frå rettleiinga til ein annan leverandør.

Identifiser kvar adresser blir verande tilgjengelege, kvar omsetjinga skjer og kva kø som faktisk styrer flaskehalsen.

Tre policyar, tre slag bevis

Ei fartsgrense blir prova av ein vedvarande overføring frå den avgrensa eininga medan ei anna overfører samtidig. Rettferdig deling blir prova av to straumar som når liknande fart i staden for at éin svelter, noko som er ei anna måling. Applikasjonsprioritet blir prova av at ein interaktiv oppgåve blir verande responsiv under ein stor overføring, og ved å sjekke at klassifiseraren i det heile tok att straumen. Kvar policy krev si eiga observasjon, og ingen blir prova av ei konfigurasjonsside.

Klassifisering fortener spesiell mistanke. Ein match på den ytre krypterte porten kan ikkje gjenopprette identiteten til kvar indre applikasjon, så ei regel som ser ut til å prioritere éin applikasjon kan i praksis prioritere alt frå den tunnelen. Les teljarane til regelen i staden for hensikta.

Mål den krypterte belastninga, ikkje den bare

Forming, klassifisering og kryptering konkurrerer om éin CPU, og maskinvareakselerasjon kan føre trafikk forbi nettopp dei reglane og teljarane du overvaker. Eit gjennomstrøymingstal frå ein vanleg rutartest seier lite om boksen under ei kryptert og forma belastning. Test begge retningar, fleire representative klientar og ei lita interaktiv oppgåve ved sida av den store overføringa. Responsivitet under belastning betyr meir enn topptalet på ei ledig linje.

Ta med unntaka i målinga: trafikk som skal gå utanom tunnelen, begge adressefamiliane om begge er i spel, og kva som skjer når tunnelen er nede. Ein policy som berre oppfører seg fornuftig medan tunnelen er sunn, er ein halv policy.

Skriv spesifikasjonen som tre linjer: trafikkmatch, handhevingspunkt og den målte belastninga. OpenVPN pluss QoS er ikkje ein spesifikasjon.