Adaptor OpenVPN berkedip di Windows? Periksa IP ganda

Di Windows, adaptor OpenVPN yang mengambil alamat, melepasnya, dan mengulanginya setiap beberapa detik biasanya bukan bug DHCP. Adaptor diperintahkan memakai alamat yang sudah dijawab oleh hal lain, jadi Windows menandainya tidak dapat dipakai dan klien memulai ulang. Log klien tetap sunyi karena konflik diselesaikan di bawahnya, di dalam tumpukan jaringan sistem operasi itu sendiri.

Perbedaan itu penting, karena setiap langkah pemecahan masalah yang menyasar konfigurasi terowongan akan melewatkan alamat ganda di sisi server.

Mulailah dari log peristiwa Windows, bukan log klien

Windows mencatat konflik alamat di log Sistem, dengan ID peristiwa 4198 dan 4199. Yang pertama melaporkan konflik yang terdeteksi untuk sebuah alamat, yang kedua melaporkan bahwa sebuah antarmuka tidak dapat memakai alamat yang dikonfigurasi untuknya. Keduanya tidak menyebut OpenVPN, dan justru karena itulah keduanya mudah terlewat.

Ambil peristiwa terbaru dan bandingkan stempel waktunya dengan siklus pembaruan adaptor: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konflik setiap lima belas detik cocok dengan klien yang mencoba ulang alamat yang sama terhadap pemilik yang terus menjawabnya. Konflik tunggal saat koneksi justru menunjuk pada tabrakan sekali saja. Bagaimanapun, pertanyaan berikutnya adalah siapa lagi yang memegang alamat itu.

Tiga pengaturan menempatkan dua host pada satu alamat

Tanyakan kepada server siapa yang menurutnya memegang alamat itu, lalu tanyakan kepada jaringan siapa yang menjawabnya. grep -H ifconfig-push /etc/openvpn/ccd/* mencantumkan setiap alamat terowongan yang dipatok dan sertifikat miliknya. ip -4 neigh show dev tap0 menunjukkan apa yang telah dipelajari jembatan di lapisan kedua. Membandingkan kedua daftar itu menemukan sebagian besar duplikat dalam waktu kurang dari satu menit.

Tiga pengaturan menjelaskan hampir semuanya: entri client-config-dir mematok satu alamat untuk dua sertifikat, segmen tap yang dijembatani memberi mesin alamat yang sudah dimiliki host lain secara statis, atau file sewa yang basi mengembalikan alamat yang dianggap milik klien yang masih terhubung. Kasus ketiga paling licik, karena ifconfig-pool-persist sengaja memakai ulang alamat untuk klien yang dikenal.

Buat alamat itu unik, bukan berlomba untuk mendapatkannya

Urutan boot hanya menentukan siapa yang menang hari ini, jadi perlakukan setiap perbaikan yang bergantung pada urutan mulai ulang sebagai sementara. Beri setiap klien baris ifconfig-push miliknya sendiri, atau alokasikan alamat statis dari rentang yang tidak disentuh antarmuka jembatan atau server mana pun. Periksa juga daftar klien untuk nama umum yang ganda, karena duplicate-cn memungkinkan dua sesi berbagi satu identitas dan karena itu satu alamat yang dipatok. Jika perangkat yang dijembatani benar-benar membutuhkan alamat tetap, pindahkan ke subnetnya sendiri atau pesan dari kumpulan di tempat yang dicatat server.

Hapus file persist hanya setelah Anda tahu sewa mana yang dipegangnya, jika tidak koneksi ulang berikutnya akan membagikan alamat yang sama lagi.

Mulai ulang dalam urutan yang benar dan pastikan satu pemilik per alamat

Terapkan perubahan di server lebih dulu, lalu hubungkan ulang klien, agar setiap peserta mendaftar terhadap kumpulan yang telah diperbaiki. Memulai ulang klien lebih dulu membuat mereka tetap memegang alamat yang masih dianggap terpakai oleh server. Setelah mulai ulang, baca file status dan pastikan setiap nama umum muncul sekali dengan satu alamat. Dua entri untuk satu nama berarti sesi lama tidak pernah ditutup, bukan berarti kumpulannya rusak.

Jika klien masih tidak dapat mempertahankan alamatnya, periksa apakah antarmuka jembatan di host yang sama membawanya. Jembatan yang mewarisi alamat dari perangkat vendor akan menjawab ARP untuknya bahkan ketika server VPN sudah menyerahkan alamat itu kepada klien.

Amati selama satu siklus pembaruan penuh sebelum menutup tiket

Satu pembacaan bersih tidak membuktikan apa pun. Amati adaptor setidaknya sepuluh menit dan paksa koneksi ulang di tengahnya: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Alamat seharusnya bertahan melewati koneksi ulang dan tetap dalam status yang disukai.

Lalu jalankan lagi kueri peristiwa dari langkah pertama dan pastikan tidak mengembalikan hal baru. Log yang sunyi sepanjang koneksi ulang adalah bukti konfliknya hilang, sedangkan log yang sunyi setelah satu koneksi hanya berarti perlombaan belum terjadi. Terakhir, uji sumber daya yang menjadi alasan terowongan itu ada, karena jembatan yang kehilangan alamatnya dapat merusak jalur vendor sementara VPN itu sendiri tampak sehat.

Catat rentang kumpulan, setiap alamat yang dipatok, dan host yang memilikinya di catatan server. Dengan begitu tabrakan berikutnya terlihat dalam hitungan menit, bukan butuh sepanjang sore untuk menemukannya lagi.