Cara membedakan loop perutean dari rute yang berkedip di situs VPN
Loop perutean dan rute yang berkedip menyebabkan kehilangan intermiten yang sama. Tiga pemeriksaan di gateway membedakan keduanya sebelum Anda mengubah apa pun.
Dua situs, satu terowongan, dan satu prefiks jauh yang menjawab beberapa saat lalu diam. Refleksnya adalah menyebutnya loop perutean, dan kadang memang persis itu. Tetapi loop dan rute yang berkedip menghasilkan keluhan yang sama dan membutuhkan perbaikan yang berlawanan: yang satu adalah keputusan penerusan yang tidak pernah berakhir, yang lain adalah prefiks yang terus meninggalkan tabel. Tiga pengamatan memisahkan keduanya, dan Anda dapat mengumpulkan ketiganya dari baris perintah gateway sebelum menyentuh filter atau memulai ulang terowongan.
Loop diputuskan hop demi hop. Situs A memilih B sebagai hop berikutnya untuk tujuan, B memilih A untuk tujuan yang sama, dan paket berakhir pada TTL setelah dua perjalanan pulang-pergi. Kedipan sebaliknya diputuskan oleh protokol perutean: prefiks ditarik, dipasang ulang, atau diganti dengan hop berikutnya alternatif, sehingga sebagian paket tidak punya rute sama sekali sementara yang lain mengikuti rute yang sangat baik.
Tiga pemeriksaan yang menyelesaikan pertanyaan
Anda tidak perlu tangkapan paket untuk mengambil keputusan pertama. Anda perlu keadaan prefiks di kedua ujung, hop berikutnya yang dipilih tiap sisi, dan jumlah hop yang berulang atau tidak. Jika prefiks tetap terpasang dengan hop berikutnya yang sama sementara lalu lintas gagal, loop hidup di jalur penerusan. Jika prefiks hilang dan kembali, gangguannya berada di atas penerusan dan perbaikannya milik protokol perutean, bukan rute statis.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Satu peringatan sebelum mulai. Jika Anda membaca ini melalui terowongan yang berloop, sesi Anda mati saat Anda mengubah rute. Buka konsol atau jalur manajemen yang tidak bergantung pada prefiks yang akan Anda perbaiki.
Pemeriksaan satu: apakah prefiks stabil atau bergejolak
Tanyakan kepada kernel apa yang dipasangnya, bukan apa yang dijanjikan berkas konfigurasi. Di gateway Linux, ip route get 10.20.30.40 menjalankan pencarian yang sama dengan jalur penerusan, termasuk tabel kebijakan, sedangkan ip route show 10.20.30.0/24 menampilkan entrinya sendiri. ip monitor route mengalirkan setiap perubahan saat terjadi, yang merupakan cara tercepat mengamati prefiks datang dan pergi.
Pada router yang menjalankan FRR atau BIRD, tabel penerusan bukan yang menarik. show ip bgp 10.20.30.0/24 mengembalikan jalur terpilih dan waktu aktifnya; waktu aktif yang direset setiap beberapa menit adalah kedipan yang bisa Anda namai, bukan loop. show ip bgp summary menampilkan keadaan tetangga dan jumlah prefiks, sehingga peer yang terus jatuh melepas kesalahan dari jalur penerusan.
Tuliskan jawabannya sebelum mengubah apa pun. Stabil selama sepuluh menit sementara ping gagal, dan hilang empat kali dalam sepuluh menit, mengarah ke langkah berikut yang berbeda. Yang kedua membuat semua teori rute statis tidak relevan.
Pemeriksaan dua: apakah hop berikutnya menunjuk kembali ke terowongan kedatangan
Loop membutuhkan dua gateway yang sepakat. Di situs yang menerima paket, lihat rute yang akan dipakai paket untuk keluar: ip route get 10.20.30.40 from 10.10.5.20 dengan alamat sumber sebenarnya, karena aturan kebijakan bisa menjawab berbeda dari tabel utama. Lalu ulangi pencarian di situs yang mengirimnya. Jika tiap sisi memilih yang lain sebagai hop berikutnya untuk prefiks yang sama, loop terbukti dan tidak ada tangkapan yang akan menambahkan apa pun.
Penyebabnya hampir selalu pengumuman yang seharusnya tidak menyeberangi terowongan. Rute default yang didistribusikan ulang ke dalam terowongan, agregat yang menutupi subnet situs jauh itu sendiri, atau rute statis yang menunjuk ke peer untuk berjaga-jaga semuanya menciptakan hop berikutnya timbal balik yang sama. Terowongan bisa sepenuhnya terbentuk dan tetap membawa lalu lintas berputar; catatan penerusan strongSwan menjelaskan sisi perutean dari persyaratan itu.
WireGuard layak mendapat catatan sendiri, karena tidak ada pengumuman yang bisa disalahkan. wg show mencantumkan AllowedIPs tiap peer, dan kernel hanya menerima tujuan untuk satu peer jika jatuh di dalam rentang itu. Loop di sana adalah rentang AllowedIPs yang tumpang tindih atau rute statis yang menunjuk kembali melintasi antarmuka, jadi perbaikannya hidup di dua tempat itu dan tidak di tempat lain.
Pemeriksaan tiga: bacalah jumlah hop, bukan bintang
traceroute -n -I 10.20.30.40 dan mtr -n -r -c 20 10.20.30.40 keduanya menunjukkan jalur, dan mode ICMP sering bertahan dari penyaringan yang memakan probe UDP. Loop terlihat seperti urutan pendek berulang dari dua alamat gateway yang sama dengan TTL naik setiap kali. Jatuh terlihat seperti bintang setelah gateway terakhir yang menjawab, dan satu hop sunyi bukan bukti apa pun.
Ketika jalurnya ambigu, bacalah TTL di kabel. tcpdump -ni any -vv icmp pada kedua gateway menunjukkan TTL tiap paket dan alamat sumber tiap balasan waktu terlampaui. Jika sebuah paket mencapai situs jauh dengan TTL lebih rendah daripada jumlah hop yang bisa dimuat jalur, sesuatu menambahkan hop yang tidak ditunjukkan traceroute kepada Anda, dan itu terjadi ketika firewall satu situs menjawab probe atas nama situs lain.
Perbaiki pemilik prefiks, lalu verifikasi kedua arah
Putuskan situs mana yang menghasilkan tujuan dan jalur transit mana yang diizinkan, lalu ubah pengumuman atau rute statis di pemilik itu. Memperbaiki situs penerima menggiurkan dan biasanya salah: itu menyembunyikan loop untuk satu prefiks dan meninggalkan pengumuman buruk di tempatnya untuk prefiks berikutnya. Tag rute, daftar distribusi, dan aturan split-horizon ada untuk menghentikan ini di sumbernya, dan itu lebih murah daripada filter yang cocok dengan satu prefiks.
Setelah perubahan, verifikasi arah pergi dan kembali secara terpisah, karena loop bisa diganti dengan lubang hitam tanpa perbaikan gejala yang terlihat. Jalankan ip route get dari kedua ujung, kirim lalu lintas dari host yang bukan gateway, dan biarkan ip monitor route berjalan setidaknya satu pengatur waktu tahan agar kedipan tidak disalahartikan sebagai perbaikan.
Sebelum mengubah apa pun, pastikan lima hal ini: prefiks stabil atau bergejolak, hop berikutnya di kedua ujung menunjuk ke terowongan, jumlah hop berulang atau tidak, satu situs memiliki prefiks, dan Anda memegang jalur manajemen yang bertahan terhadap perubahan. Jika salah satu dari lima tidak diketahui, empat lainnya adalah dugaan.