Amaran AF_INET OpenVPN: sandaran tidak berbahaya atau socket yang gagal?

Dua baris log OpenVPN bermula dengan perkataan yang sama, dan hanya satu daripadanya melaporkan masalah. Could not determine IPv4/IPv6 protocol. Using AF_INET ialah pemberitahuan sandaran: profil membiarkan keluarga alamat terbuka, jadi daemon memilih satu dan meneruskan. Cabang kegagalan melaporkan bahawa tiada socket dicipta dan meminta mula semula. Semua yang selepas awalan bersama memisahkan kedua-duanya, jadi baca melewatinya sebelum mengubah apa-apa.

Apa yang dilaporkan pemberitahuan sandaran

OpenVPN menerima keluarga eksplisit melalui proto udp4 atau proto udp6, dan menerima proto udp apabila keluarga perlu diterbitkan semasa permulaan. Dalam kes kedua daemon memeriksa maklumat pengikatan setempat dan memilih.

Apabila terbitan itu berfungsi, amaran menyatakan arah mana ia pergi dan proses meneruskan penciptaan socket. Pelayan dengan proto udp pada hos dwi-tindanan sering berakhir di IPv4 dengan cara ini. Tiada apa-apa pada laluan itu yang merupakan ralat, dan tiada apa-apa di dalamnya membayangkan serangan, pelayan web yang hilang atau akaun yang ditolak. Baris itu berguna hanya kerana pemeriksaan kemudian harus dibandingkan dengan keluarga yang dinamakannya.

Anggap ia sebagai jawapan kepada satu soalan, bukan diagnosis. Ia memberitahu keluarga mana yang dipilih oleh proses ini, dan tiada apa-apa tentang mengapa klien tidak boleh menyambung.

Bagaimana rupa cabang kegagalan

Kemudian dalam kod socket yang sama terdapat cabang di mana tiada socket sama sekali. Ia mencatat mesej keluarga alamat yang lebih pendek dan meminta mula semula, kerana tiada apa-apa lagi untuk diteruskan. Perkataan pembukaan sepadan dengan sandaran; hasilnya tidak.

Bezakan kedua-duanya dengan apa yang menyusul. Jika daemon terus berjalan dan melaporkan pendengarnya, baris itu ialah maklumat. Jika ia keluar atau mula semula dalam gelung, perbualan sekarang tentang pengikatan.

Penemuan grep juga bukan pengenalpastian cabang. Frasa itu muncul dalam ringkasan berputar, dalam baris terlipat dan dalam petikan log yang orang tampal dari tangan kedua, jadi baca baris jiran dan susunan cap masa dan bukan padanan tunggal.

Periksa pendengar dan bukan amaran

Pelayan yang berjalan menjawab soalan keluarga secara langsung, tanpa membuat kesimpulan daripada teks log.

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

Padankan keluarga, alamat dan port dengan profil. Baris 0.0.0.0:1194 hanya IPv4, manakala baris [::]:1194 pada hos dwi-tindanan boleh menerima kedua-dua keluarga bergantung pada tetapan bindv6only. Jika profil menyebut udp dan socket ialah IPv4, klien yang penyelesainya hanya mengembalikan rekod AAAA akan gagal sebelum terowong sempat dirundingkan.

Kemudian uji daripada klien yang menyerupai pengguna anda: laluan penyelesai yang sama, jenis rangkaian yang sama. Sambungan setempat daripada pelayan membuktikan sangat sedikit tentang trafik yang melintasi peranti NAT atau peraturan dinding api yang ditulis untuk keluarga lain.

Bila memaksa keluarga itu betul

Menyemat proto udp4 sesuai untuk penggunaan hanya-IPv4: nama DNS hanya A, peraturan dinding api untuk satu alamat v4, klien di belakang pengendali yang hanya memberi alamat v4. Ia menghapuskan kekaburan dan menjadikan set baris log seterusnya boleh diramal.

Hujah yang sama berfungsi sebaliknya untuk persekitaran yang mengutamakan IPv6, dan udp6 di hadapan asas klien hanya A ialah gangguan yang anda sebabkan sendiri. Memaksa keluarga hanya untuk menyenyapkan amaran tidak berbahaya ialah versi klasik kesilapan ini, kerana anda telah menukar siapa yang boleh menyambung sebagai pertukaran untuk log yang lebih tenang.

Pilih berdasarkan titik akhir dan klien yang mesti mencapainya. Panduan OpenVPN 2.6 mendokumenkan bentuk pengangkutan, dan mesej itu ialah output pilihan tersebut, bukan inputnya.

Kekalkan rekod sempit

Catat baris yang tepat dengan cap masanya, tetapan pengangkutan berkesan daripada profil yang berjalan, socket seperti yang dilaporkan oleh kernel, dan peringkat seterusnya yang gagal. Empat perkara itu menyelesaikan hampir setiap soalan yang ditimbulkan oleh mesej, dan tiada satu pun memerlukan tekaan tentang perkhidmatan yang tidak berkaitan. Ia juga bertahan semasa penyerahan, yang tidak dilakukan oleh tangkapan skrin grep.

Cadangan pakej yang datang bersama amaran ini tidak berkaitan sehingga ralat menamakan fail boleh laku yang hilang.

Jika ifconfig benar-benar tiada, daemon menyebutnya dengan nama apabila skrip memanggilnya, dan itu wajar disiasat sendiri. Baris AF_INET dan utiliti yang hilang ialah kegagalan yang berbeza, dan memasang perkara untuk melihat sama ada amaran berubah ialah cara hos bersih menjadi bersepah.