TUN/TAP: argumen tidak valid — ketidakcocokan framing OpenVPN

Klien terautentikasi, log menyebut terhubung, dan tidak ada paket yang melintasi tunnel. Server mengakhiri percobaan dengan write to TUN/TAP: Invalid argument (code=22), yang terlihat seperti kerusakan driver dan biasanya bukan. Di router dan server Linux kecil, baris itu paling sering berarti kedua ujung tidak sepakat tentang cara paket data dibingkai, sehingga kernel menolak buffer terdekripsi yang diberikan kepadanya. Perutean belum diuji pada titik itu.

Tabel rute yang benar dan kesepakatan framing yang rusak terlihat sama dari sisi klien: terhubung, dan tidak ada yang berfungsi.

Tunnel naik dan tidak ada yang melintasinya

Kesalahan tulis pada perangkat tunnel terjadi setelah dekripsi dan sebelum perutean. Daemon mendekripsi paket, menyerahkannya ke antarmuka, dan antarmuka menolaknya karena buffer tidak cocok dengan yang diharapkan perangkat itu. Kode 22 adalah jawaban umum untuk argumen tidak valid, jadi informasi yang berguna adalah lapisannya: ini jalur data, bukan handshake. Jika lalu lintas berjalan kemarin dan berhenti hari ini tanpa perubahan konfigurasi, curigai pembaruan paket atau firmware yang menggeser nilai bawaan sebelum mencurigai jaringan.

Baca log di sekitar penyiapan kanal data alih-alih kesalahan pertama. Mode kompresi yang dinegosiasikan, jenis dev, dan opsi yang didorong semuanya muncul pada verbositas lebih tinggi, dan itu memberi tahu Anda ketidakcocokan mana dari ketiganya yang Anda miliki.

Kompresi adalah framing, bukan bandwidth

Saat kompresi diaktifkan, setiap paket data membawa header yang menjelaskan bagaimana paket itu dikodekan, dan kedua ujung harus sepakat soal header itu. Server yang masih membawa comp-lzo dari konfigurasi contoh lama, dipasangkan dengan klien tanpa baris kompresi, menghasilkan persis kesalahan ini: server mengharapkan header yang tidak pernah ditulis klien. Mencampur comp-lzo dengan compress lz4-v2 gagal dengan cara yang sama, karena algoritmanya berbeda meski keduanya disebut kompresi. Opsi ini adalah kontrak framing, bukan fitur bandwidth pada tautan modern.

Perilaku versi menambahkan jebakan. Seri 2.5 mulai mengeluarkan peringatan usang untuk opsi kompresi, dan 2.6 menarik garis antara menolak paket terkompresi dan sekadar membiarkan data tidak terkompresi. Pembaruan firmware router karena itu dapat mengubah kesepakatan efektif tanpa ada yang menyunting tunnel.

Selaraskan kedua ujung atau hapus dari keduanya

Sebutkan setiap direktif kompresi: file server, opsi apa pun yang didorong, file khusus klien, dan profil klien. comp-lzo di server membutuhkan kata yang sama di klien, dan adaptive adalah nilai bawaan lama yang biasanya dimaksud opsi telanjang pada build lebih tua. Sakelar GUI router berlabel LZO atau kompresi menulis opsi yang sama, jadi setel agar cocok alih-alih mencampur algoritme. Jangan menganggap nama yang mirip itu kompatibel.

Jika kompresi tidak diinginkan, hapus dengan sengaja dari kedua ujung. allow-compression no di server menolak paket terkompresi, tetapi hanya setelah klien berhenti menawarkannya; menerapkannya saat klien masih mendorong kompresi akan menciptakan kembali ketidakcocokan ke arah sebaliknya.

Periksa dorongan dan jenis perangkat

Server dapat mendorong direktif kompresi dari file utamanya atau dari file khusus klien, dan klien dapat membuang opsi yang didorong dengan pull-filter. Hubungkan satu klien pada verbositas 4, baca apa yang diumumkan server terhadap apa yang diterima klien, lalu pastikan tidak ada filter yang menghapusnya. Jika kedua sisi sekarang sepakat dan kesalahan tetap ada, lihat jenis perangkat: dev tap di satu ujung dan dev tun di ujung lain tidak dapat bertukar frame, dan kernel menolak penulisan dengan cara yang sama.

Penerapan TAP berjembatan memerlukan jembatan sungguhan di server, bukan hanya nama perangkat yang berbeda. Mengganti nama antarmuka menjadi tap0 tanpa menambahkannya ke jembatan menghasilkan perangkat yang menerima penulisan dan tidak pergi ke mana pun.

Lalu verifikasi dengan satu klien dan satu tujuan: ping alamat tunnel server, lalu host di LAN-nya. Yang pertama membuktikan kanal data dan yang kedua membuktikan penerusan.