Penghalaan rekursif: apabila terowong menangkap paketnya sendiri
Terowong boleh menangkap paket yang membinanya. Bandingkan laluan ke pelayan sebelum dan selepas perubahan laluan lalai, kemudian betulkan pemilik laluan itu.
Terowong naik, log menunjukkan jabat tangan yang selesai, dan sesaat kemudian sesi yang sama mati dan menyambung semula dalam gelung. Corak itu mempunyai punca tertentu: laluan ke pelayan kini menunjuk ke dalam terowong, jadi paket yang membawa terowong dihantar melalui terowong. Tiada apa yang berubah pada pengesahan, sebab itu memasukkan semula kelayakan tidak mengubah apa-apa. Bandingkan laluan luar sebelum dan selepas perubahan laluan dan rekursi menjadi kelihatan.
Periksa laluan luar dahulu
Ada dua paket dalam permainan, bukan satu. Paket dalam milik aplikasi dan sepatutnya disulitkan, manakala paket luar dialamatkan kepada pelayan dan mesti mencapainya melalui laluan yang tidak bergantung pada terowong.
ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints
Tanya kernel tentang laluan ke alamat pelayan selepas terowong naik, dan sekali lagi selepas laluan lalai berubah. Hop seterusnya yang mendarat pada peranti terowong itulah rekursinya, dan ia kelihatan tanpa sebarang tangkapan paket. Pengikatan antara muka, tanda atau ruang nama rangkaian boleh menjadikan carian biasa tidak lengkap, jadi gunakan konteks yang digunakan oleh klien itu sendiri. Apabila jawapannya kelihatan betul tetapi sesi masih berputar dalam gelung, baca peraturan dasar penghalaan dan bukan hanya jadual utama.
Mengapa sesi bertahan seketika
Jabat tangan selesai sebelum laluan baharu dipasang, jadi detik-detik pertama kelihatan sihat. Sebaik klien menambah laluan lalai, paket luar seterusnya mengikutinya masuk ke antara muka yang perlu dilalui paket luar itu. Pelayan tidak melihat apa-apa, klien menghantar semula, dan percubaan itu sama ada tamat masa atau membunuh sesi dan bermula semula.
Urutan itu menjelaskan mengapa terowong boleh berfungsi pada komputer riba dan gagal pada penghala, dan mengapa kegagalan sering bermula apabila trafik bermula dan bukan pada masa menyambung. Ia juga menjelaskan gelung itu: setiap permulaan semula menubuhkan semula sesi sebelum laluan menjadikannya mustahil.
Cari siapa pemilik pengecualian titik akhir
Klien yang disokong menyediakan pengecualian mereka sendiri: laluan hos ke pelayan melalui get laluan asal, atau tanda yang mengekalkan soket luar di luar terowong. Persoalannya ialah sama ada sesuatu yang lain telah mengeluarkannya atau mengatasinya.
Dalam IPsec berasaskan laluan, periksa pemilih dasar yang menentukan paket mana yang masuk ke terowong dan sahkan bahawa alamat rakan sebaya dikecualikan daripadanya. Dalam WireGuard, tanda tembok api antara muka dan peraturan dasarnya mengekalkan paket pengangkutan di luar terowong, jadi laluan lalai yang ditambah secara manual boleh merosakkan susunan itu. Profil VPN kedua atau skrip pengurusan yang menulis semula laluan lalai ialah punca yang lazim. Peraturan pintasan luas yang ditambah satu demi satu ialah hasil biasa, dan ia mengubah pepijat penghalaan menjadi jadual yang tiada siapa dapat menyelenggarakannya.
Periksa semula selepas perubahan rangkaian
Laluan hos melalui get laluan Wi-Fi adalah betul sehingga mesin berpindah ke rangkaian lain. Gejala yang sama kemudian kembali tanpa sebarang perubahan konfigurasi.
Catat alamat titik akhir, laluan sebelum dan selepas menyambung, dan antara muka yang digunakan oleh setiap satu. Ketiga-tiga fakta itu biasanya memisahkan pepijat klien daripada pengatasan, dan ia kekal selepas orang yang mengumpulnya pergi.
Sambung semula pada rangkaian baharu dan ulangi bacaan. Jika pengecualian itu hilang lagi, pembetulan itu milik profil yang memilikinya, bukan arahan sekali sahaja yang ditaip semasa gangguan.