Peringatan AF_INET OpenVPN: fallback tak berbahaya atau socket yang gagal?

Dua baris log OpenVPN dimulai dengan kata yang sama, dan hanya satu di antaranya melaporkan masalah. Could not determine IPv4/IPv6 protocol. Using AF_INET adalah pemberitahuan fallback: profil membiarkan keluarga alamat terbuka, jadi daemon memilih satu dan melanjutkan. Cabang kegagalan melaporkan bahwa tidak ada socket yang dibuat dan meminta mulai ulang. Semua yang setelah awalan bersama memisahkan keduanya, jadi bacalah lewat awalan itu sebelum mengubah apa pun.

Apa yang dilaporkan pemberitahuan fallback

OpenVPN menerima keluarga eksplisit melalui proto udp4 atau proto udp6, dan menerima proto udp ketika keluarga harus diturunkan saat mulai. Pada kasus kedua daemon memeriksa informasi pengikatan lokal dan memilih.

Ketika penurunan itu berhasil, peringatan menyebutkan arah yang diambil dan proses berlanjut membuat socket. Server dengan proto udp pada host tumpukan ganda cukup sering berakhir di IPv4 dengan cara ini. Tidak ada yang salah pada jalur itu, dan tidak ada yang menyinggung serangan, server web yang hilang, atau akun yang ditolak. Baris itu berguna hanya karena pemeriksaan berikutnya harus dibandingkan dengan keluarga yang disebutnya.

Perlakukan sebagai jawaban atas satu pertanyaan, bukan diagnosis. Ia memberi tahu keluarga mana yang dipilih proses ini, dan tidak sama sekali mengapa klien tidak dapat terhubung.

Seperti apa cabang kegagalan itu

Nanti dalam kode socket yang sama ada cabang yang tidak memiliki socket sama sekali. Ia mencatat pesan keluarga alamat yang lebih pendek dan meminta mulai ulang, karena tidak ada yang tersisa untuk dilanjutkan. Kata-kata pembukanya sama dengan fallback; hasilnya tidak.

Bedakan keduanya dari apa yang menyusul. Jika daemon terus berjalan dan melaporkan listener-nya, baris itu adalah informasi. Jika ia keluar atau mulai ulang dalam lingkaran, sekarang pembicaraannya tentang pengikatan.

Temuan grep juga bukan identifikasi cabang. Frasa itu muncul di ringkasan yang diputar, di baris terlipat, dan di kutipan log yang ditempel orang dari tangan kedua, jadi bacalah baris tetangga dan urutan stempel waktu alih-alih satu kecocokan.

Periksa listener alih-alih peringatan

Server yang berjalan menjawab pertanyaan keluarga secara langsung, tanpa menyimpulkan dari teks log.

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

Cocokkan keluarga, alamat, dan port dengan profil. Baris 0.0.0.0:1194 hanya IPv4, sedangkan baris [::]:1194 pada host tumpukan ganda dapat menerima kedua keluarga tergantung pengaturan bindv6only. Jika profil mengatakan udp dan socket-nya IPv4, klien yang resolver-nya hanya mengembalikan catatan AAAA akan gagal sebelum terowongan sempat dinegosiasikan.

Lalu uji dari klien yang mirip pengguna Anda: jalur resolver sama, jenis jaringan sama. Koneksi lokal dari server membuktikan sangat sedikit tentang lalu lintas yang melewati perangkat NAT atau aturan firewall yang ditulis untuk keluarga lain.

Kapan memaksa keluarga itu tepat

Menyematkan proto udp4 cocok untuk penerapan hanya-IPv4: nama DNS hanya A, aturan firewall untuk satu alamat v4, klien di belakang operator yang hanya memberi alamat v4. Ini menghilangkan ambiguitas dan membuat rangkaian baris log berikutnya dapat diprediksi.

Argumen yang sama berlaku sebaliknya untuk lingkungan yang mengutamakan IPv6, dan udp6 di depan basis klien hanya A adalah gangguan yang Anda sebabkan sendiri. Memaksa keluarga hanya untuk membungkam peringatan tak berbahaya adalah versi klasik kesalahan ini, karena Anda mengubah siapa yang dapat terhubung dengan imbalan log yang lebih tenang.

Pilih berdasarkan titik akhir dan klien yang harus mencapainya. Panduan OpenVPN 2.6 mendokumentasikan bentuk transportasi, dan pesannya adalah keluaran dari pilihan itu, bukan masukannya.

Jaga catatan tetap sempit

Catat baris persisnya dengan stempel waktunya, pengaturan transportasi efektif dari profil yang berjalan, socket sebagaimana dilaporkan kernel, dan tahap berikutnya yang gagal. Keempat hal itu menyelesaikan hampir semua pertanyaan yang diajukan pesan, dan tidak satu pun perlu menebak layanan yang tidak terkait. Semuanya juga bertahan saat serah terima, yang tidak dilakukan tangkapan layar grep.

Saran paket yang datang bersama peringatan ini tidak terkait sampai ada kesalahan yang menyebut file eksekusi yang hilang.

Jika ifconfig benar-benar tidak ada, daemon menyebutnya dengan nama saat skrip memanggilnya, dan itu layak diselidiki sendiri. Baris AF_INET dan utilitas yang hilang adalah kegagalan yang berbeda, dan memasang hal-hal untuk melihat apakah peringatan berubah adalah cara host yang bersih menjadi berantakan.