Klien OpenVPN tersekat apabila pelayan berjalan pada hos yang sama
Dua instans OpenVPN pada satu hos bersaing untuk port tempatan dan jadual laluan yang sama. Pin port itu, pisahkan peranti, dan semak jadual mana yang menang.
Saya mempunyai mesin makmal yang menerima terowong dari tapak jauh dan juga mendail keluar ke rangkaian vendor. Profil keluar telah berfungsi selama berminggu-minggu. Selepas pelayan masuk ditambah, yang keluar bersambung dan kemudian berhenti menghantar trafik dalam beberapa saat, atau enggan bermula dengan ralat alamat sudah digunakan. Fail konfigurasi tidak berubah; hos hanya memperoleh proses OpenVPN kedua yang mempunyai pendapat sendiri tentang port dan laluan.
Kegagalan ini bukan rawak, dan ia bukan masalah pengesahan. Dua daemon pada satu mesin bersaing untuk soket tempatan yang sama dan jadual laluan yang sama, dan yang bermula atau bersambung semula terakhir biasanya menang. Mengetahui yang mana antara dua perlanggaran ini anda ada menentukan di mana perlu dilihat dahulu.
Baca simptom secara terbalik
Mulakan dengan bila terowong mati. Ralat ikatan semasa bermula menunjuk ke sisi mendengar: sesuatu sudah memiliki port itu, dan OpenVPN enggan bermula daripada berkongsinya. Terowong yang naik dan kemudian senyap menunjuk ke penghalaan, kerana laluan yang dipasang oleh instans lain boleh menarik paket sambungan luar dari laluannya.
Kedua-dua kes menghasilkan aduan pengguna yang sama, sebab itulah gelung cubaan semula dan skrip pengawas tidak membaiki apa-apa. Ia menyambung semula klien ke dalam konflik yang sama. Soalan pertama yang berguna ialah sama ada proses itu masih berjalan apabila trafik berhenti.
Satu soket dan satu peranti setiap instans
Pelayan yang mendengar mengikat portnya; klien keluar juga memerlukan port tempatan untuk trafik terkapsulnya. Apabila kedua-duanya tinggal pada hos yang sama, tingkah laku lalai klien boleh berlanggar dengan port pelayan. Port tempatan klien boleh dipin, dan pengikatan boleh dilangkau di tempat rakan tidak memerlukan port sumber tetap:
lport 1195
nobind
dev tun1Nombor itu contoh, bukan keperluan. Yang penting ialah klien berhenti bersaing untuk port pelayan dan setiap instans mendapat peranti terowong berasingan. Dua daemon yang berkongsi tun0 menimpa keadaan peranti satu sama lain walaupun port mereka berbeza, jadi satu peranti setiap terowong bukan pilihan.
nobind milik sisi klien. Pelayan masih mesti mengikat dan mendengar, jadi jangan salin baris itu ke konfigurasi pelayan, dan jangan lumpuhkan pengikatan pada klien yang rakannya menapis pada port sumber tetap.
Pilih satu pemilik untuk laluan lalai
Hanya satu sambungan boleh memasang laluan lalai. Jika kedua-dua profil mengubah hala semua trafik, sambungan kedua secara senyap menggantikan yang pertama, dan yang pertama kelihatan rosak. Sama ada kekalkan terowong keluar berpecah dan tolak hanya awalan vendor, atau berikannya jadual penghalaan berasingan.
ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2Alamat dan nombor jadual di atas ialah pemegang tempat. Sejurus selepas menambah peraturan, sahkan bahawa alamat pelayan VPN itu sendiri masih diselesaikan melalui jadual biasa; jadual yang menangkap pengangkutan luar memecahkan terowong yang sepatutnya dilindunginya, dan gelung sambung semula yang menyusul kelihatan seperti pembekal yang tidak boleh dipercayai.
Untuk persediaan yang mesti bertahan daripada sambung semula dan but semula, ruang nama rangkaian ialah sempadan yang lebih kukuh. Klien kedua berjalan di dalam ruang namanya sendiri dengan antara muka dan laluannya sendiri, dan hanya perkhidmatan yang mesti melintasi yang didedahkan. Hos mengekalkan satu laluan lalai, dan sambung semula ruang nama tidak boleh menulis semula laluan itu.
Sahkan dengan jadual, bukan baris status
Klien yang melaporkan bersambung hanya membuktikan saluran kawalannya. Tangkap keadaan penghalaan sebelum dan selepas setiap sambungan, kemudian tanya kernel peranti mana yang akan digunakan oleh destinasi sebenar:
ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194Jika peranti yang dipilih untuk alamat vendor berubah apabila terowong kedua bermula, anda mempunyai perlanggaran laluan. Jika kedua-dua proses muncul pada port tempatan yang sama, anda mempunyai perlanggaran soket. Membaiki yang pertama tanpa yang kedua hanya memindahkan kegagalan ke sambung semula seterusnya.
Tulis port, peranti, jadual dan pemilik laluan ke dalam runbook hos. Jika tidak, orang seterusnya yang menambah terowong ketiga akan menemui semula perlanggaran yang sama, dan satu-satunya bukti yang kelihatan ialah sambungan yang berfungsi sehingga daemon orang lain dimulakan semula.