TUN/TAP: argument i pavlefshëm — mospërputhje e kornizimit të OpenVPN
Gabimet e shkrimit me kodin 22 zakonisht nënkuptojnë që dy palët nuk bien dakord për kornizimin e paketave të dhënave, jo një defekt të drejtuesit. Krahasoni kompresimin në të dy skajet, pastaj llojin e pajisjes.
Klienti autentifikohet, regjistri thotë i lidhur, dhe asnjë paketë nuk kalon nëpër tunel. Serveri e përfundon përpjekjen me write to TUN/TAP: Invalid argument (code=22), që duket si defekt i drejtuesit dhe zakonisht nuk është. Në ruterë dhe serverë të vegjël Linux, ajo rresht zakonisht do të thotë që dy palët nuk bien dakord se si kornizohen paketat e dhënave, kështu që kerneli refuzon buferin e dekriptuar që iu dha. Rrugëtimi nuk është testuar në atë pikë.
Një tabelë rrugëtimi e saktë dhe një marrëveshje kornizimi e thyer duken njësoj nga ana e klientit: i lidhur, dhe asgjë nuk funksionon.
Tuneli ngrihet dhe asgjë nuk e kalon
Gabimet e shkrimit në pajisjen e tunelit ndodhin pas dekriptimit dhe para rrugëtimit. Daemoni dekripton një paketë, ia dorëzon ndërfaqes, dhe ndërfaqja e refuzon sepse buferi nuk përputhet me atë që pret ajo pajisje. Kodi 22 është përgjigja e përgjithshme për argument të pavlefshëm, kështu që informacioni i dobishëm është shtresa: kjo është rruga e të dhënave dhe jo shtrëngimi i duarve. Nëse trafiku funksiononte dje dhe u ndal sot pa asnjë ndryshim konfigurimi, dyshoni një përditësim pakete ose firmueri që zhvendosi një vlerë të parazgjedhur përpara se të dyshoni rrjetin.
Lexoni regjistrin rreth konfigurimit të kanalit të të dhënave në vend të gabimit të parë. Modaliteti i kompresimit i negociuar, lloji dev dhe opsionet e shtyra shfaqen të gjitha në një nivel më të lartë detajesh, dhe ju tregojnë se cilën nga tre mospërputhjet keni.
Kompresimi është kornizim, jo gjerësi bande
Kur kompresimi është aktivizuar, çdo paketë e dhënave mbart një kokë që përshkruan si u kodua, dhe të dy skajet duhet të bien dakord për atë kokë. Një server që ende mbart comp-lzo nga një konfigurim i vjetër shembull, i çiftuar me një klient pa rresht kompresimi, prodhon pikërisht këtë gabim: serveri pret një kokë që klienti nuk e ka shkruar kurrë. Përzierja e comp-lzo me compress lz4-v2 dështon në të njëjtën mënyrë, pasi algoritmet ndryshojnë edhe pse të dy quhen kompresim. Opsioni është një kontratë kornizimi dhe jo një funksion i gjerësisë së bandës në lidhjet moderne.
Sjellja e versioneve shton një kurth. Seria 2.5 filloi të lëshojë paralajmërime vjetërsie për opsionet e kompresimit, dhe 2.6 tërheq një vijë midis refuzimit të paketave të kompresuara dhe thjesht lënies së të dhënave të pakompresuara. Një përditësim firmueri i ruterit mund të ndryshojë pra marrëveshjen efektive pa redaktuar askush tunelin.
Rreshtoni të dy skajet ose hiqeni nga të dyja
Numëroni çdo direktivë kompresimi: skedarin e serverit, çdo opsion të shtyrë, skedarët specifikë për klientin dhe profilin e klientit. comp-lzo në server kërkon të njëjtën fjalë në klient, dhe adaptive është vlera e parazgjedhur e trashëguar që opsioni i zhveshur zakonisht nënkupton në ndërtimet më të vjetra. Ndërprerësi GUI i ruterit i etiketuar LZO ose kompresim shkruan të njëjtin opsion, kështu që vendoseni të përputhet në vend që të përzieni algoritmet. Mos supozoni se një emër i ngjashëm është i përputhshëm.
Nëse kompresimi nuk dëshirohet, hiqeni me qëllim nga të dy skajet. allow-compression no në server refuzon paketat e kompresuara, por vetëm pasi klientët të kenë pushuar së ofruari ato; zbatimi i tij ndërsa një klient ende shtyn kompresimin rikrijon mospërputhjen në drejtimin tjetër.
Kontrolloni shtyrjen dhe llojin e pajisjes
Një server mund të shtyjë një direktivë kompresimi nga skedari i tij kryesor ose nga një skedar specifik për klientin, dhe një klient mund të hedhë poshtë opsionet e shtyra me pull-filter. Lidhni një klient në detaje 4, lexoni çfarë njoftoi serveri kundrejt asaj që pranoi klienti, më pas konfirmoni që asnjë filtër nuk e hoqi atë. Nëse të dyja palët tani bien dakord dhe gabimi vazhdon, shikoni llojin e pajisjes: dev tap në njërin skaj dhe dev tun në tjetrin nuk mund të shkëmbejnë korniza, dhe kerneli refuzon shkrimin në të njëjtën mënyrë.
Një vendosje TAP me urë kërkon një urë të vërtetë në server, jo vetëm një emër tjetër pajisjeje. Riemërtimi i një ndërfaqeje në tap0 pa e shtuar në një urë prodhon një pajisje që pranon shkrimin dhe nuk shkon askund.
Pastaj verifikoni me një klient dhe një destinacion: bëni ping adresën e tunelit të serverit, pastaj një host në LAN-in e tij. I pari vërteton kanalin e të dhënave dhe i dyti përcjelljen.