VPN Terputus Selepas Pembaharuan DHCP? Bandingkan Alamat

Pembaharuan pajakan dan kegagalan VPN cukup kerap muncul bersama dalam log sehingga orang membuat kesimpulan bahawa satu menyebabkan yang lain. Kebetulan masa itu nyata; kekasualannya biasanya tidak. Pembaharuan ialah permintaan unicast kepada pelayan yang mengeluarkan pajakan, meminta terus menggunakan pengikatan yang sama, dan pelayan boleh memanjangkannya tanpa klien menukar satu alamat pun. Meneliti nilai klien sendiri di sekitar peristiwa memisahkan pajakan yang diperbaharui secara senyap daripada rangkaian yang benar-benar berubah di bawah terowong yang berjalan.

Mulakan dengan klien yang terputus

Buka log sambungan klien dahulu dan catat masa pemutusan hingga ke saat. Kemudian buka log rangkaian sistem pengendalian untuk minit yang sama dan baca mengikut urutan apa yang dilakukan antara muka. Urutan ini ialah seluruh penyiasatan: peristiwa DHCP sebelum pemutusan, pemutusan sebelum peristiwa DHCP, dan dua peristiwa tanpa apa-apa di antaranya ialah tiga penemuan berbeza. Baris log yang hanya menyebut pajakan semasa terowong sudah menyambung semula ialah hiasan, bukan bukti.

Tulis garis masa sambil berjalan dan bukan menyimpannya dalam ingatan. Cap masa daripada alat berbeza jarang sepadan sepenuhnya, dan selisihnya sendiri kadangkala menjadi penjelasan.

Bandingkan empat nilai di sekitar peristiwa

Empat nilai cukup menggambarkan sisi tempatan sesuatu sambungan untuk menangkap perubahan sebenar: alamat antara muka, get laluan lalai, senarai penyelesai dan keadaan operasi antara muka. Ambilnya dalam masa seminit selepas pemutusan dan bandingkan dengan tangkapan yang diambil semasa terowong sihat.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Alamat yang tidak berubah dengan get laluan yang tidak berubah dan senarai penyelesai yang berubah menunjuk kepada penyelesaian nama dan bukan penghalaan, dan terowong mungkin terselamat semasa aplikasi berhenti menemui hos. Get laluan yang berubah bermaksud laluan keluar dari rangkaian tempatan telah bergerak, dan itu cukup untuk membatalkan laluan yang menunjuk ke yang sebelumnya. Jika keempat-empat nilai sepadan dengan tangkapan sihat, pajakan bukan penyebab anda dan logik penyambungan semula klien sendiri menjadi topik. Ambil perbandingan semasa kerosakan kelihatan, kerana tangkapan sihat yang diambil selepas but semula mempunyai sejarah alamat berbeza dan tidak akan sepadan.

Apa yang boleh dan tidak boleh diubah oleh pembaharuan

RFC 2131 menerangkan pembaharuan sebagai permintaan kepada pelayan asal pada separuh masa pajakan, dengan pengikatan semula kepada mana-mana pelayan pada tujuh perlapan jika percubaan pertama tidak dijawab. Kedua-dua langkah tidak memerlukan klien memperoleh alamat berbeza, dan pelayan yang bekerjasama biasanya memanjangkan pengikatan sedia ada. Perubahan alamat sebenar biasanya datang melalui laluan lain: pelayan menolak pembaharuan, klien kehilangan keadaannya dan bermula semula, atau rangkaian memindahkan peranti ke segmen lain.

Sisi awam sambungan boleh berubah tanpa sebarang perubahan tempatan. Di sebalik terjemahan gred pembawa, alamat yang dilihat oleh rakan VPN boleh diperuntukkan semula secara bebas daripada apa yang dilakukan oleh pajakan tempatan, dan peruntukan semula itu kelihatan sama seperti kegagalan rangkaian tempatan dari dalam klien. Membandingkan alamat yang dilaporkan secara tempatan dengan pemerhatian sisi rakan ialah satu-satunya cara untuk memisahkannya.

Apabila klien gagal menyesuaikan diri

Klien yang mengikat pengangkutannya kepada alamat lama, menyimpan laluan usang ke rakan atau menyimpan identiti antara muka mungkin terus mencuba laluan yang tidak lagi wujud. Itu kecacatan penyesuaian, dan ia kelihatan sebagai penghantaran semula berulang ke alamat yang hos tidak lagi dapat capai. Sesetengah klien mengendalikannya secara reka bentuk: WireGuard, misalnya, mengemas kini titik akhir rakan apabila paket yang disahkan dengan betul tiba dari sumber baharu.

Mula semula secara manual yang memulihkan perkhidmatan ialah petunjuk tentang di mana penyesuaian gagal, bukan bukti bahawa pajakan dan terowong tidak serasi. Kekalkan dasar penyekatan semasa ujian, jika tidak ujian itu sendiri menjadi gangguan dengan sebab lain. Catat sama ada klien pulih sendiri, berapa lama ia mengambil masa dan alamat mana yang dicuba semula; urutan itu memberitahu anda lebih daripada sebab pemutusan yang ditunjukkan dalam antara muka.

Ulang peristiwa sebelum menyalahkannya

Hasilkan semula keadaan dan bukan menunggu jadual: lepaskan dan perbaharui pajakan, atau paksakan peristiwa terkawal yang setara, dan perhatikan sama ada terowong bertahan. Dalam rangkaian terurus, selaraskan sebarang perubahan alamat dengan pemilik rangkaian, kerana penugasan statik sewenang-wenang boleh berlanggar dengan peranti yang sudah memegang alamat itu.

Selepas pembetulan yang disokong, ulangi peristiwa yang sama dan kemudian uji aplikasi dan carian nama, kerana terowong yang menyambung semula tetapi merosakkan DNS lulus ujian yang lebih lemah daripada yang penting. Laporkan perubahan khusus yang anda perhatikan, dengan cap masanya, dan bukan menamakan pajakan berjadual sebagai punca. Perbezaan antara kedua-dua laporan itu ialah sama ada orang seterusnya boleh menghasilkan semula kerosakan atau hanya khabar angin.