TUN/TAP: hindi wastong argumento — hindi tugma ang framing ng OpenVPN

Nagpapatunay ang kliyente, sinasabi ng log na konektado, at walang packet na tumatawid sa tunnel. Tinatapos ng server ang pagtatangka gamit ang write to TUN/TAP: Invalid argument (code=22), na mukhang sira ng driver at karaniwang hindi. Sa mga router at maliliit na Linux server, ang linyang iyon ay kadalasang nangangahulugang hindi nagkakasundo ang dalawang dulo sa paraan ng pag-frame ng mga data packet, kaya tinatanggihan ng kernel ang na-decrypt na buffer na ibinigay dito. Hindi pa nasubukan ang routing sa puntong iyon.

Ang tamang routing table at sirang kasunduan sa framing ay magkamukha mula sa kliyente: konektado, at walang gumagana.

Bumabangon ang tunnel at walang tumatawid dito

Ang mga error sa pagsulat sa device ng tunnel ay nangyayari pagkatapos ng decryption at bago ang routing. Dinidecrypt ng daemon ang isang packet, ibinibigay ito sa interface, at tinatanggihan ito ng interface dahil hindi tumutugma ang buffer sa inaasahan ng device na iyon. Ang code 22 ay ang pangkalahatang sagot para sa hindi wastong argumento, kaya ang kapaki-pakinabang na impormasyon ay ang layer: ito ang data path at hindi ang handshake. Kung gumana ang traffic kahapon at huminto ngayon nang walang pagbabago sa configuration, maghinala ng update ng package o firmware na naglipat ng default bago maghinala sa network.

Basahin ang log sa paligid ng setup ng data channel sa halip na ang unang error. Ang napagkasunduang compression mode, ang uri ng dev at ang mga pushed na opsyon ay lumilitaw lahat sa mas mataas na verbosity, at sinasabi nila kung alin sa tatlong hindi pagkakatugma ang mayroon ka.

Ang compression ay framing, hindi bandwidth

Kapag naka-enable ang compression, bawat data packet ay may dalang header na naglalarawan kung paano ito na-encode, at dapat magkasundo ang dalawang dulo sa header na iyon. Ang server na may dalang pa rin ng comp-lzo mula sa lumang sample na configuration, isinama sa kliyenteng walang linya ng compression, ay gumagawa ng eksaktong error na ito: inaasahan ng server ang header na hindi kailanman isinulat ng kliyente. Ang paghahalo ng comp-lzo sa compress lz4-v2 ay nabibigo rin sa parehong paraan, dahil magkaiba ang algorithm kahit parehong tinatawag na compression. Ang opsyon ay kontrata ng framing at hindi feature ng bandwidth sa mga modernong link.

Ang pag-uugali ng mga bersyon ay nagdaragdag ng bitag. Nagsimulang maglabas ang seryeng 2.5 ng mga babala sa pagka-luma para sa mga opsyon ng compression, at ang 2.6 ay gumuhit ng linya sa pagitan ng pagtanggi sa mga compressed na packet at ng basta pag-iwan sa data na hindi compressed. Kaya maaaring baguhin ng update ng firmware ng router ang epektibong kasunduan nang walang nag-edit ng tunnel.

Ihanay ang dalawang dulo o alisin mula sa dalawa

Ilahad ang bawat direktiba ng compression: ang file ng server, anumang pushed na opsyon, mga file na partikular sa kliyente at ang profile ng kliyente. Ang comp-lzo sa server ay nangangailangan ng parehong salita sa kliyente, at ang adaptive ay ang legacy na default na karaniwang ibig sabihin ng hubad na opsyon sa mas lumang build. Ang switch ng GUI ng router na may label na LZO o compression ay nagsusulat ng parehong opsyon, kaya itakda ito upang tumugma sa halip na paghaluin ang mga algorithm. Huwag ipagpalagay na tugma ang magkatulad na pangalan.

Kung hindi kailangan ang compression, alisin ito nang sadya mula sa dalawang dulo. Ang allow-compression no sa server ay tumatanggi sa mga compressed na packet, ngunit pagkatapos lamang na huminto ang mga kliyente sa pag-aalok ng mga ito; ang paglalapat nito habang nagtutulak pa ang kliyente ng compression ay muling lumilikha ng hindi pagkakatugma sa kabilang direksyon.

Suriin ang pagtutulak at ang uri ng device

Maaaring magtulak ang server ng direktiba ng compression mula sa pangunahing file nito o mula sa file na partikular sa kliyente, at maaaring itapon ng kliyente ang mga pushed na opsyon gamit ang pull-filter. Ikonekta ang isang kliyente sa verbosity 4, basahin ang inihayag ng server kumpara sa tinanggap ng kliyente, pagkatapos ay kumpirmahin na walang filter na nag-alis nito. Kung magkasundo na ang dalawang panig at nananatili ang error, tingnan ang uri ng device: ang dev tap sa isang dulo at dev tun sa kabila ay hindi makakapagpalitan ng frame, at tinatanggihan din ng kernel ang pagsulat sa parehong paraan.

Ang naka-bridge na deployment ng TAP ay nangangailangan ng tunay na bridge sa server, hindi lamang ibang pangalan ng device. Ang pagpalit ng pangalan ng interface sa tap0 nang hindi ito idinaragdag sa isang bridge ay gumagawa ng device na tumatanggap ng pagsulat at hindi napupunta kahit saan.

Pagkatapos ay i-verify gamit ang isang kliyente at isang destinasyon: i-ping ang tunnel address ng server, pagkatapos ang isang host sa LAN nito. Ang una ay nagpapatunay ng data channel at ang pangalawa ng pagpapasa.