Adapters OpenVPN berkelip di Windows? Periksa IP pendua

Di Windows, adapter OpenVPN yang mengambil alamat, melepaskannya dan mengulanginya setiap beberapa saat biasanya bukan pepijat DHCP. Adapter diberitahu untuk menggunakan alamat yang sudah dijawab oleh sesuatu yang lain, jadi Windows menandakannya tidak boleh digunakan dan klien bermula semula. Log klien kekal senyap kerana konflik diselesaikan di bawahnya, di dalam tindanan rangkaian sistem pengendalian itu sendiri.

Perbezaan itu penting, kerana setiap langkah penyelesaian masalah yang menyasarkan konfigurasi terowong akan terlepas alamat pendua di sebelah pelayan.

Mulakan dengan log peristiwa Windows, bukan log klien

Windows merekodkan konflik alamat dalam log Sistem, dengan ID peristiwa 4198 dan 4199. Yang pertama melaporkan konflik yang dikesan untuk sesuatu alamat, yang kedua melaporkan bahawa antara muka tidak dapat menggunakan alamat yang dikonfigurasikan untuknya. Kedua-duanya tidak menyebut OpenVPN, dan kerana itulah ia mudah terlepas pandang.

Dapatkan peristiwa terkini dan bandingkan cap masanya dengan kitaran pembaharuan adapter: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konflik setiap lima belas saat sepadan dengan klien yang mencuba semula alamat yang sama terhadap pemilik yang terus menjawabnya. Konflik tunggal semasa sambungan sebaliknya menunjukkan perlanggaran sekali sahaja. Walau apa pun, soalan seterusnya ialah siapa lagi yang memegang alamat itu.

Tiga susunan meletakkan dua hos pada satu alamat

Tanya pelayan siapa yang difikirkannya memegang alamat itu, kemudian tanya rangkaian siapa yang menjawabnya. grep -H ifconfig-push /etc/openvpn/ccd/* menyenaraikan setiap alamat terowong yang dipin dan sijil yang dimilikinya. ip -4 neigh show dev tap0 menunjukkan apa yang telah dipelajari jambatan pada lapisan kedua. Membandingkan kedua-dua senarai itu menemui kebanyakan pendua dalam masa kurang seminit.

Tiga susunan menjelaskan hampir semuanya: entri client-config-dir memin satu alamat untuk dua sijil, segmen tap yang dijambatankan memberi mesin alamat yang sudah dimiliki hos lain secara statik, atau fail sewa yang lapuk memulangkan alamat yang dianggap milik klien yang masih bersambung. Kes ketiga paling licik, kerana ifconfig-pool-persist sengaja menggunakan semula alamat untuk klien yang dikenali.

Jadikan alamat itu unik dan bukannya berlumba untuknya

Urutan but hanya menentukan siapa yang menang hari ini, jadi anggap sebagai sementara apa-apa pembetulan yang bergantung pada urutan mula semula. Beri setiap klien baris ifconfig-push miliknya sendiri, atau peruntukkan alamat statik daripada julat yang tidak disentuh oleh mana-mana antara muka jambatan atau pelayan. Periksa juga senarai klien untuk nama biasa yang pendua, kerana duplicate-cn membenarkan dua sesi berkongsi satu identiti dan oleh itu satu alamat yang dipin. Jika peranti yang dijambatankan benar-benar memerlukan alamat tetap, pindahkannya ke subnetnya sendiri atau tempah daripada kumpulan di tempat yang dicatatkan oleh pelayan.

Padam fail persist hanya selepas anda tahu sewa mana yang dipegangnya, jika tidak sambungan semula seterusnya akan mengagihkan alamat yang sama sekali lagi.

Mulakan semula dalam urutan yang betul dan sahkan satu pemilik bagi setiap alamat

Gunakan perubahan pada pelayan dahulu, kemudian sambung semula klien, supaya setiap peserta mendaftar terhadap kumpulan yang telah dibetulkan. Memulakan semula klien dahulu menyebabkan mereka memegang alamat yang masih dianggap terpakai oleh pelayan. Selepas mula semula, baca fail status dan sahkan setiap nama biasa muncul sekali dengan satu alamat. Dua entri untuk satu nama bermakna sesi lama tidak pernah ditutup, bukan kumpulan itu rosak.

Jika klien masih tidak dapat mengekalkan alamatnya, periksa sama ada antara muka jambatan pada hos yang sama membawanya. Jambatan yang mewarisi alamat daripada peranti vendor akan menjawab ARP untuknya walaupun pelayan VPN sudah menyerahkan alamat itu kepada klien.

Perhatikan sepanjang kitaran pembaharuan penuh sebelum menutup tiket

Satu bacaan bersih tidak membuktikan apa-apa. Perhatikan adapter sekurang-kurangnya sepuluh minit dan paksa sambungan semula di tengahnya: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Alamat itu sepatutnya bertahan melalui sambungan semula dan kekal dalam keadaan pilihan.

Kemudian jalankan semula pertanyaan peristiwa dari langkah pertama dan sahkan ia tidak memulangkan apa-apa yang baharu. Log yang senyap sepanjang sambungan semula adalah bukti konflik itu telah hilang, manakala log senyap selepas satu sambungan hanya bermakna perlumbaan itu belum berlaku. Akhir sekali, uji sumber yang menjadi tujuan terowong itu wujud, kerana jambatan yang kehilangan alamatnya boleh memecahkan laluan vendor sedangkan VPN itu sendiri kelihatan sihat.

Catat julat kumpulan, setiap alamat yang dipin dan hos yang memilikinya dalam nota pelayan. Dengan itu perlanggaran seterusnya dapat dikesan dalam beberapa minit dan bukannya memerlukan sepanjang petang untuk menemukannya semula.