TUN/TAP: hujah tidak sah — ketidakpadanan pembingkaian OpenVPN

Klien mengesahkan identiti, log menyatakan bersambung, dan tiada paket melintasi terowong. Pelayan menamatkan cubaan dengan write to TUN/TAP: Invalid argument (code=22), yang kelihatan seperti kerosakan pemacu dan biasanya bukan. Pada penghala dan pelayan Linux kecil, baris itu selalunya bermaksud kedua-dua hujung tidak bersetuju tentang cara paket data dibingkaikan, jadi kernel menolak penimbal dinyahsulit yang diberikan kepadanya. Penghalaan belum diuji pada ketika itu.

Jadual penghalaan yang betul dan perjanjian pembingkaian yang rosak kelihatan sama dari sisi klien: bersambung, dan tiada apa berfungsi.

Terowong naik dan tiada apa melintasinya

Ralat menulis pada peranti terowong berlaku selepas nyahsulit dan sebelum penghalaan. Daemon menyahsulit paket, menyerahkannya kepada antara muka, dan antara muka menolaknya kerana penimbal tidak sepadan dengan apa yang peranti itu jangkakan. Kod 22 ialah jawapan umum untuk hujah tidak sah, jadi maklumat berguna ialah lapisan: ini laluan data, bukan jabat tangan. Jika trafik berjalan semalam dan berhenti hari ini tanpa perubahan konfigurasi, syak kemas kini pakej atau perisian tegar yang mengalihkan nilai lalai sebelum menyak rangkaian.

Baca log sekitar persediaan saluran data dan bukan ralat pertama. Mod pemampatan yang dirundingkan, jenis dev dan pilihan yang ditolak semuanya muncul pada kejituan lebih tinggi, dan ia memberitahu anda ketidakpadanan mana antara tiga yang anda ada.

Pemampatan ialah pembingkaian, bukan lebar jalur

Apabila pemampatan diaktifkan, setiap paket data membawa pengepala yang menerangkan cara ia dikodkan, dan kedua-dua hujung mesti bersetuju tentang pengepala itu. Pelayan yang masih membawa comp-lzo daripada konfigurasi contoh lama, dipadankan dengan klien yang tiada baris pemampatan, menghasilkan ralat ini dengan tepat: pelayan menjangkakan pengepala yang tidak pernah ditulis klien. Mencampur comp-lzo dengan compress lz4-v2 gagal dengan cara yang sama, kerana algoritma berbeza walaupun kedua-duanya dipanggil pemampatan. Pilihan itu ialah kontrak pembingkaian dan bukan ciri lebar jalur pada pautan moden.

Tingkah laku versi menambah perangkap. Siri 2.5 mula mengeluarkan amaran pengusangan untuk pilihan pemampatan, dan 2.6 menarik garis antara menolak paket termampat dan hanya membiarkan data tidak termampat. Kemas kini perisian tegar penghala kerana itu boleh mengubah perjanjian berkesan tanpa sesiapa menyunting terowong.

Selaraskan kedua-dua hujung atau buang daripada kedua-duanya

Senaraikan setiap arahan pemampatan: fail pelayan, sebarang pilihan yang ditolak, fail khusus klien dan profil klien. comp-lzo pada pelayan memerlukan perkataan yang sama pada klien, dan adaptive ialah nilai lalai warisan yang biasanya dimaksudkan oleh pilihan bogel pada binaan lama. Suis GUI penghala berlabel LZO atau pemampatan menulis pilihan yang sama, jadi tetapkan ia sepadan dan bukan mencampur algoritma. Jangan anggap nama yang serupa penampilannya serasi.

Jika pemampatan tidak dikehendaki, buangnya dengan sengaja daripada kedua-dua hujung. allow-compression no pada pelayan menolak paket termampat, tetapi hanya selepas klien berhenti menawarkannya; menggunakan apabila klien masih menghantar pemampatan mencipta semula ketidakpadanan ke arah yang lain.

Periksa tolakan dan jenis peranti

Pelayan boleh menolak arahan pemampatan daripada fail utamanya atau daripada fail khusus klien, dan klien boleh membuang pilihan yang ditolak dengan pull-filter. Sambungkan satu klien pada kejituan 4, baca apa yang diumumkan pelayan berbanding apa yang diterima klien, kemudian sahkan tiada penapis membuangnya. Jika kedua-dua pihak kini bersetuju dan ralat kekal, lihat jenis peranti: dev tap di satu hujung dan dev tun di hujung lain tidak dapat bertukar bingkai, dan kernel menolak penulisan dengan cara yang sama.

Penggunaan TAP berjambatan memerlukan jambatan sebenar pada pelayan, bukan hanya nama peranti yang berbeza. Menamakan semula antara muka kepada tap0 tanpa menambahnya kepada jambatan menghasilkan peranti yang menerima penulisan dan tidak pergi ke mana-mana.

Kemudian sahkan dengan satu klien dan satu destinasi: ping alamat terowong pelayan, kemudian hos pada LAN-nya. Yang pertama membuktikan saluran data dan yang kedua pembaikan penghantaran.