OpenVPN-i liikluse vormimine: milline liides seda näeb?

Käige läbi neli kontrolli: mida soovite piirata, milline pakett kannab teavet, mis seda identifitseerib, millist liidest vormija näeb ja mida ruuter krüpteerimise ajal talub. Ruuterid tulevad nii OpenVPN lehe kui ka ribalaiuse lehega ning nende kooseksisteerimine ei tõesta kummagi kohta midagi. Järjekord on oluline, sest vale paketi vastu kirjutatud reegel ei sobi kunagi, ükskõik kui õige on selle kiirus.

Alustage eesmärgist: piirata ühte seadet, jagada mahtu õiglaselt või eelistada ühte rakendust. Igaüks vajab erinevat vastet.

Nimetage eesmärk enne reeglit

Seadmepõhine piirang vajab vastet selle seadme aadressile, mis eksisteerib ainult tunnelis. Õiglus konkureerivate voogude vahel vajab järjekorda, mida nad kõik jagavad, mitte reeglit iga hosti kohta. Rakenduse prioriteet vajab midagi, mis rakendust identifitseerib, mis on kolmest kõige raskem, kui krüpteerimine eemaldab sisemised päised vaateväljast. Eesmärgi esmalt kirjapanek ütleb teile, millist fakti vajate ja kust võiksite selle saada.

Piirang, mis töötab otsese WAN-liikluse korral, ei ole tõestus, et sama host on tunnelis kaetud. Reegel võib sobida aadressiga, mis ei esine kunagi päises, mida vormija näeb.

Tunneli sees või väljaspool

Ruuteri omanduses oleva VPN-kliendiga liigub palju LAN-i vooge ühe krüpteeritud transpordi sees. Enne kapseldamist näeb ruuter veel sisemist allikat ja sihtkohta, seega selles etapis lisatud poliitika saab seadme kaupa liigitada. Pärast kapseldamist näeb tavaline seade ainult välist ühendust ja vaste VPN-pordil ei ütle midagi selle kohta, milline seade on vastutav. See üks fakt otsustab, kuhu reegel kuulub.

Platvormid erinevad selle poolest, kuidas nad seda välja toovad. Mõned pakuvad vormijat, mis järjekordab ja liigitab tunneliliidesel; teised käsitlevad piirajaid liidese reeglitena, mis käituvad VPN- ja mitte-VPN-liikluse puhul ühtemoodi; mõned teevad mõlemat erinevate võimalustega. Lugege püsivara enda dokumentatsiooni liidese kohta, mida see toetab, selle asemel et kopeerida liidese nimi teise tootja juhendist.

Tehke kindlaks, kus aadressid jäävad kättesaadavaks, kus toimub tõlkimine ja milline järjekord tegelikult kitsaskohta kontrollib.

Kolm poliitikat, kolme liiki tõendid

Kiiruspiirangut tõestab pidev ülekanne piiratud seadmelt, samal ajal kui teine seade kannab üle. Õiglast jagamist tõestavad kaks voogu, mis jõuavad sarnaste kiirusteni, selle asemel et üks nälgiks, mis on teistsugune mõõtmine. Rakenduse prioriteeti tõestab interaktiivne ülesanne, mis jääb suure ülekande ajal reageerivaks, ja kontroll, kas liigitaja voo üldse ära tundis. Iga poliitika vajab oma vaatlust ja ühtegi ei tõesta konfiguratsioonileht.

Liigitamine väärib erilist kahtlust. Välise krüpteeritud pordi vaste ei suuda taastada iga sisemise rakenduse identiteeti, seega reegel, mis näib eelistavat üht rakendust, võib praktikas eelistada kõike sellest tunnelist. Lugege reegli loendureid, mitte selle kavatsust.

Mõõtke krüpteeritud koormust, mitte paljast

Vormimine, liigitamine ja krüpteerimine konkureerivad ühe protsessori pärast ning riistvarakiirendus võib viia liikluse mööda just nendest reeglitest ja loenduritest, mida jälgite. Läbilaskevõime näitaja lihtsast marsruutimistestist ütleb vähe seadme kohta krüpteeritud ja vormitud koormuse all. Testige mõlemat suunda, mitut esinduslikku klienti ja väikest interaktiivset ülesannet suure ülekande kõrval. Koormuse all reageerimine loeb rohkem kui tippnäitaja tühjal lingil.

Kaasake mõõtmisse erandid: liiklus, mis peaks tunnelist mööda minema, mõlemad aadressiperekonnad, kui mõlemad mängus on, ja mis juhtub, kui tunnel on maas. Poliitika, mis käitub mõistlikult ainult seni, kuni tunnel on terve, on pool poliitikat.

Kirjutage spetsifikatsioon kolme reana: liikluse vaste, rakenduspunkt ja mõõdetud koormus. OpenVPN pluss QoS ei ole spetsifikatsioon.