Compression sa OpenVPN: tanggihan, tanggapin lang o buong LZO?

Tatlong linya sa isang profile ang mukhang pinapatay lahat ang compression, at isa lang sa kanila ang tunay na gumagawa nito. Mahalaga ang pagkakaiba dahil sintomas lang ang babala na nais mong patahimikin, samantalang ang patakaran ang nagtatakda kung makakapag-compress pa ang kabilang dulo. Ang paghahambing ng mga opsyon sa isang axis, ibig sabihin kung ano ang pinapayagan ng bawat isa pagkatapos ng pagbabago, ay nag-aalis ng halos lahat ng kalabuan. Alin ang gusto mo ay depende sa kung lumilipat ka o nagpapakatatag.

Tatlong patakaran na magkamukha sa isang config file

Bawat opsyon ay sumasagot sa ibang tanong. Tinatanggihan ng allow-compression no ang mga naka-compress na payload nang deretso, binubuksan ng allow-compression asym ang dumarating at hindi kailanman nagko-compress ng lumalabas, at ang lumang comp-lzo no ay nag-iiwan ng puwang para sa push ng kabilang dulo upang buksan ang compression. Ang una lang ang patakarang hindi kayang lampasan ng server.

Isulat ang tatlo sa isang talahanayan bago pumili, dahil masyadong magkalapit ang mga pangalan para mailigaw ang tagasuri. Dalawa sa kanila ay nagpapatakbo pa ng decompression code sa mga natanggap na packet, at iyon mismo ang pinag-uusapan ng argumento sa seguridad. Tinatanggal ng ikatlo ang kakayahan sa halip na limitahan ang direksyon nito. Kung ang tala ng pagbabago ay nagsasabing patay ang compression, eksaktong isang hilera ang tumutugma sa pangungusap na iyon.

Ang babala na nagpasimula ng imbestigasyon ay hindi ang layunin. Ang patahimikin ito habang nananatili ang mapagpahintulot na patakaran ay nagbibigay ng malinis na log at hindi nagbago ang pagkakalantad.

Ano ang ibig sabihin ng no sa lumang opsyon na LZO

Sa lipas na opsyon na LZO, pinapatay ng no ang compression sa lokal na panig nang hindi ipinagbabawal sa kabilang dulo na buksan ito kung saan pinapayagan ng patakaran. Dahil sa asimetriyang iyon, ang paglilipat ng profile sa mahigpit na pagtanggi ay nagbabago ng pag-uugali sa mga paraang maaaring hindi kailanman ibunyag ng isang-server na pagsubok sa laboratoryo.

Ang alalahanin sa seguridad ay may kondisyon, hindi ganap. Kapag ang isang umaatake ay makapaglalagay ng piniling plaintext sa tabi ng isang sikreto at makamasid kung paano binabago ng compression ang laki ng naka-encrypt na trapiko, mayroong channel ng impormasyon. Ang paglipat mula LZO sa LZ4 ay nagbabago ng algorithm at framing, hindi ang mekanismong iyon.

Kaya ang tapat na balangkas ay tungkol sa kung ano ang handa mong payagan, hindi sa kung aling algorithm ang inirerekomenda ngayon. Ang mahigpit na pagtanggi ang tanging opsyon na hindi umaasa sa pakikipagtulungan ng kabilang dulo.

Ang tanggapin lang ay isang kalagayan ng paglilipat, hindi destinasyon

Umiiral ang asimetrikong pagtanggap upang ang isang panig ay makapagpahinto sa pag-compress habang ang kabila ay umaasa pa rin dito. Ito ay tulay, at ang mga tulay ay nangangailangan ng petsa ng pagtatapos at may-ari. Itala kung aling mga peer ang nagpapadala pa ng naka-compress na trapiko, dahil pinapayagan ng patakaran ang mismong trapikong iyon. Kung wala ang listahang iyon, ang kalagayan ng paglilipat ay nagiging permanenteng config dahil sa pagkakatigil.

Hindi kayang pilitin ng kliyente ang isang hindi tugmang server na talikuran ang lumang framing sa pamamagitan ng pag-edit ng sarili nitong file. Ang direksyon ng push ay pinagpapasyahan sa server, kaya doon talaga nagtatapos ang paglilipat sa config ng server at sa mga file nito bawat kliyente.

Ang mga stub mode ay nagpapanatili ng framing ngunit nilalaktawan ang gawain ng compression mismo, at hindi sila direktang katumbas ng lumang opsyon. Subukan ang mga ito laban sa pinakalumang peer na kailangan mo pang suportahan bago pumili ng isa.

Kung saan binabago ng offload ng data channel ang sagot

Inililipat ng offload ng data channel ang paghawak ng packet sa kernel, at ang profile na umaasa pa sa compression framing ay maaaring hindi umangkop sa landas na iyon. Hindi laging maingay ang pagkabigo: kumokonekta ang kliyente at pagkatapos ay kumikilos nang iba kaysa sa tunnel na sinubukan mo.

Tingnan kung aling implementasyon ang aktibo bago at pagkatapos ng pagbabago, hindi lang kung nagtagumpay ang koneksyon. Kapag tinatanggihan ng landas na may offload ang compression framing, nagtutugma ang mahigpit na patakaran ng pagtanggi at ang deployment na may offload, samantalang ang mapagpahintulot na patakaran at ang deployment na may offload ay hindi.

Ang kombinasyong iyon ay karapat-dapat sa sarili nitong pagsubok, dahil doon mismo ang isang file na mukhang tama ay tahimik na hindi ang ginagamit. Ihambing ang napagkasunduang kalagayan sa intensyong naitala sa profile, dahil isa lang sa dalawa ang nakikita sa log.

Pumili ng patakaran, pagkatapos i-verify ang napagkasunduang resulta

Piliin ang mahigpit na pagtanggi kapag kayang baguhin ang magkabilang dulo, ang asimetrikong pagtanggap kapag hindi pa kaya, at ang buong compression lamang kapag kayang ipaliwanag kung bakit katanggap-tanggap ang pagkakalantad. Pagkatapos ay i-verify ang napagkasunduan sa halip na ang sinasabi ng file. Ang mas tahimik na log ay ebidensya lamang kapag tumutugma sa patakarang balak mong ilagay.

Itabi ang desisyon sa tabi ng profile na naaangkop ito, kasama ang petsa at ang mga peer na binigyan pa ng exemption. Makalipas ang anim na buwan, ang tala na iyon ang pagkakaiba ng sinadyang pagbubukod at aksidenteng walang makapagsasabi ng petsa. Isulat ito sa parehong repository tulad ng profile upang makita ng susunod na editor ang dahilan bago ang direktiba.