IP WAN berubah dan terowong terputus: semakan mengikut urutan

Terowong terputus, penghala merekodkan sambungan semula, dan tiada apa bergerak di LAN. Alamat WAN baharu membatalkan sambungan luar tanpa mengubah apa-apa di dalam: alamat sumber klien telah berubah, keadaan NAT lama menunjuk kepada sumber yang tidak lagi wujud, dan rakan sebaya jauh mungkin masih menghantar ke alamat sebelumnya. Pemulihan ialah tingkah laku normal, dan soalan yang berguna ialah keadaan mana yang gagal dikemas kini.

Namakan peristiwa sebelum membaca log

Semak apa yang sebenarnya berlaku di lapisan akses. Pembaharuan pajakan ISP ialah satu peristiwa. Sesi PPPoE yang bersambung semula ialah peristiwa lain. Modem gentian yang dimulakan semula, atau failover WAN dari satu pautan ke pautan lain, mengubah alamat luar atau laluannya dengan cara ketiga. Ia bukan peristiwa yang sama dan tidak meninggalkan sisa yang sama.

Baris sambungan semula dalam log VPN juga bukan bukti perubahan WAN. Tamat masa melahu, selang pengesahan semula dan pengesanan rakan sebaya mati semuanya menghasilkan sambungan semula tanpa sebarang perubahan alamat. Bandingkan cap masa daripada log akses dengan log VPN sebelum membuat sebarang kesimpulan, dan pastikan tetingkap perbandingan cukup lebar untuk menangkap perubahan yang berlaku pada waktu malam.

Roaming dan sambungan semula ialah protokol yang berbeza

WireGuard mempunyai roaming disahkan terbina dalam protokol: apabila rakan sebaya menerima paket yang disahkan dengan betul daripada alamat sumber baharu, ia mengemas kini titik akhir rakan sebaya itu. Panduan pantas WireGuard menerangkan konfigurasi rakan sebaya yang membolehkan ini, sebab itu klien pada alamat yang berubah sering pulih tanpa permulaan semula yang kelihatan.

OpenVPN berkelakuan berbeza secara lalai. Sesi UDP boleh tamat dan bersambung semula, dan tingkah laku float pilihan membenarkan rakan sebaya yang disahkan meneruskan dari alamat baharu di mana konfigurasi membenarkannya. Terowong berasaskan TCP lebih ketat, kerana sambungan itu sendiri terikat pada pasangan alamat. Perbezaan itulah yang menentukan sama ada pemulihan kelihatan tidak kelihatan atau mengumumkan dirinya dalam log setiap kali.

Kedua-dua tingkah laku tidak mengatakan apa-apa tentang aplikasi di dalam. Terowong yang pulih tidak memulihkan sesi TCP yang sudah dianggap mati oleh rakan sebaya.

Keadaan yang bukan milik terowong

Keadaan terjemahan dan penghalaan bertahan selepas sambungan semula dengan cara yang mengejutkan orang. Entri conntrack yang dicipta untuk sumber lama mengekalkan laluan balasan terpaut pada alamat yang tidak lagi wujud, dan ia luput mengikut jadualnya sendiri, bukan apabila terowong kembali. Memulakan semula perkhidmatan terowong tidak memendekkan penantian itu, jadi pautan yang dibaiki masih boleh kelihatan rosak untuk seketika.

Laluan dan peraturan dasar boleh merujuk gateway atau antara muka lama. Set peraturan yang betul sebelum pertukaran WAN mungkin menunjuk kepada peranti yang kini mati, yang menghasilkan terowong yang melaporkan bersambung dan trafik yang tidak ke mana-mana. DNS dinamik untuk pelayan yang anda hos ialah masalah berasingan daripada klien yang memperoleh sumber baharu. Rekod itu perlu dikemas kini supaya klien jauh menemui anda, dan tiada konfigurasi sebelah klien memampas alamat yang tidak akan dihantar oleh terjemahan di hulu.

Susun semakan dari luar ke dalam

Urutan di bawah bergerak dari sambungan luar ke dalam, dan berhenti pada langkah pertama yang gagal itulah yang menjadikannya berguna: setiap semakan menyingkirkan lapisan di atasnya. Kekalkan urutan itu walaupun kerosakan kelihatan jelas.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Perintah pertama menunjukkan titik akhir semasa dan usia jabat tangan bagi setiap rakan sebaya. Kedua dan ketiga menunjukkan sama ada antara muka luar dan laluan ke titik akhir masih masuk akal. Bilangan conntrack ialah semakan kasar untuk keadaan yang tinggal daripada alamat sebelumnya, dan jurnal ialah tempat sebab sambungan semula direkodkan.

Kemudian uji dari klien LAN dan bukan dari penghala. Ping yang dihantar oleh penghala itu sendiri menggunakan laluan berbeza daripada trafik yang dimajukan, jadi ping penghala yang berjaya membuktikan terowong wujud dan tiada apa tentang kebolehcapaian klien.

Tentukan tingkah laku yang dijangka dan tuliskan

Bersambung semula ialah tingkah laku yang betul untuk kebanyakan penggunaan, jadi matlamatnya bukan menghalangnya. Tentukan sebaliknya apa yang harus berlaku kepada trafik semasa jurang: hentikannya, tahannya, atau beralih ke laluan lain. Keputusan itu milik firewall dan dasar penghalaan, bukan profil VPN.

Rakam peristiwa akses dan masa sambungan semula bersama selama seminggu. Perubahan berulang tanpa peristiwa akses yang sepadan menunjuk kepada perkhidmatan akses, dan menggantikan profil VPN tidak akan membaiki pautan yang terus berunding semula. Satu pasangan entri pada minit yang sama menyelesaikan soalan untuk insiden itu dan memberi garis dasar kepada yang seterusnya.