Netgear OpenVPN: TUN dan TAP mendengar pada port berbeza
Firmware router pengguna boleh menerbitkan pendengar TUN dan TAP pada port berbeza. Profil yang ditujukan kepada yang salah tamat masa jauh sebelum mana-mana sijil diperiksa.
Telefon menyambung ke VPN router tanpa aduan, manakala komputer riba yang menggunakan profil daripada halaman muat turun yang sama tamat masa. Tiada apa-apa tentang sijil berubah antara kedua-dua percubaan itu, kerana komputer riba itu tidak pernah sampai ke titik di mana sijil penting. Router menerbitkan pendengar berasingan untuk TUN dan TAP, dan profil yang berfungsi mesti memilih yang kepunyaan jenis perantinya sendiri.
Memutuskan kecacatan mana antara tiga calon untuk dikejar ialah keseluruhan kerja di sini: port, jenis peranti atau rundingan sifer saluran data.
Tiga perkara yang mesti sepadan
Jenis peranti, baris antara muka profil dan port pendengar membentuk satu pilihan, bukan tiga. Profil yang mengisytiharkan dev tun dan menyasarkan pendengar TAP tidak boleh melengkapkan sesi, dan sebaliknya gagal dengan cara yang sama. Untuk model dan firmware anda, baca port daripada halaman VPN router itu sendiri dan bukan daripada panduan, kerana nombornya berubah antara binaan. Tulis model dan versi firmware di sebelah nombor itu supaya orang seterusnya boleh mengesahkannya.
Laporan dari lapangan menyebut pasangan seperti 12973 untuk TUN dan 12974 untuk TAP pada satu firmware, dan nombor berbeza pada yang lain. Bacalah sebagai bukti bahawa binaan berbeza, bukan sebagai pemalar untuk disalin. Profil kemudian memerlukan nama hos yang sesuai dengan jarak: nama DNS dinamik router dan bukan alamat WAN yang akan berubah.
Selepas membetulkan port dan baris antara muka, profil kelihatan seperti konfigurasi klien biasa dengan satu baris remote dan satu baris dev. Jika kedua-duanya tidak sepadan, berapa kali pun dicuba semula tidak menghasilkan sesi.
Baca log mengikut urutan ia dicetak
Klien OpenVPN melaporkan peristiwa mengikut urutan ia berlaku, jadi baris terakhir sebelum senyap mengenal pasti lapisan yang perlu diperiksa. Apabila jalanan berakhir pada TLS Error: TLS key negotiation failed, atau hanya menunggu tindak balas pertama lalu mengalah, perbandingan sijil tidak pernah berlaku. Itu menunjuk kepada kebolehcapaian, kepada pendengar, atau kepada port yang tiada apa-apa di belakangnya. Tiada satu pun daripadanya dipulihkan dengan menggantikan fail CA.
Jalanan yang mencapai VERIFY OK dan kemudian gagal berada di tempat yang sama sekali lain, dengan puncanya sendiri. Memisahkan kedua-dua hasil itu sebelum menyentuh fail menghalang lencongan klasik melalui berkas sijil yang tidak pernah ditanya. Setelah jabat tangan selesai tetapi terowong tidak naik, lihat rundingan sifer dan bukan kebolehcapaian.
Tambahkan senarai sifer yang dijangka oleh klien moden
Klien OpenVPN terkini menolak nilai lalai lama yang masih ditawarkan oleh firmware pengguna, dan gejalanya ialah kegagalan rundingan sejurus selepas jabat tangan berjaya. Pembetulannya ialah satu baris profil yang menamakan apa yang akan diterima klien: tetapkan data-ciphers kepada AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 dan AES-128-CBC dalam urutan itu. Mana-mana algoritma yang tidak dilaksanakan oleh router tidak akan pernah dipilih, jadi senarai yang lebih panjang tidak mengenakan apa-apa selain rundingan yang sedikit lebih lama.
Menyenaraikan sifer tidak mengajar router satu yang tidak dimilikinya. Jika rundingan masih gagal, periksa sama ada halaman router mempunyai tetapan sifer sendiri dan sama ada tetapan itu mengandungi sekurang-kurangnya satu entri yang diterima klien. Dua senarai tanpa anggota bersama menghasilkan kegagalan yang sama seperti port yang salah, itulah sebabnya kedua-dua hujung wajar dilihat.
Import sekali sahaja dan bukan menyunting salinan dengan tangan
Mengimport fail yang dibetulkan ke dalam NetworkManager mengelakkan folder penuh profil yang sedikit berbeza: nmcli connection import type openvpn file client.ovpn, kemudian hidupkannya mengikut nama. Simpan profil yang diimport sebagai satu-satunya salinan yang anda sunting, dan hapuskan pertindihan yang terkumpul daripada muat turun berulang.
Kemudian uji dari luar LAN. Menyambung dari rangkaian yang sama membuktikan sangat sedikit, kerana trafik mungkin tidak melalui terowong langsung. Sahkan bahawa permintaan benar-benar keluar melalui router, bukan sekadar bahawa klien menunjukkan keadaan bersambung.
Putuskan apa yang perlu dilakukan dengan amaran
Firmware pengguna biasanya menempa autoriti sijilnya sendiri, dan klien mengeluh tentang pengesahan dengan cara yang tidak dapat ditekan oleh firmware. Nilailah sama ada aduan itu penting bagi apa yang anda lindungi dan bukan menganggap setiap amaran sebagai maut, dan jangan matikan pengesahan secara global hanya untuk mendiamkan satu mesej. Amaran yang telah anda nilai ialah risiko yang didokumenkan; tetapan pengesahan yang anda matikan tidak didokumenkan.
Apabila firmware tidak menyediakan cara yang disokong untuk membetulkan amaran yang benar-benar penting, jurang itu menyokong pengehosan VPN di tempat lain. Memilih antara membaiki profil, menerima amaran dan memindahkan titik akhir ialah keputusan tentang sejauh mana anda mempercayai sijil itu. Ambillah dengan sengaja, dan catat pilihan mana yang anda pilih, dan bukan mengklik dialog sehingga ikon menjadi hijau.