Perutean kebijakan IPv6 saat dua uplink berbagi fe80::1
Dua uplink dapat menampilkan fe80::1 yang sama sebagai hop berikutnya di tautan berbeda. Pilih satu tabel per kebijakan, miliki masa pakai, dan verifikasi dengan pencarian rute.
Anda punya dua uplink, dan ip -6 route show menampilkan hop berikutnya yang sama pada keduanya: default via fe80::1 dev uplink0 dan default via fe80::1 dev uplink1. Itu bukan konflik alamat duplikat, dan menyalin hop berikutnya telanjang fe80::1 ke tabel kebijakan tidak memberi tahu kernel tautan mana yang Anda maksud. Pertanyaan sebenarnya lebih sempit daripada gejalanya: apakah tabel kedua membutuhkan satu tautan atau keduanya, dan apa yang menjaga rute-rute itu tetap hidup setelah reboot. Tiga kondisi, diperiksa berurutan, menyelesaikan sebagian besarnya.
fe80::1 yang sama adalah dua tetangga berbeda
Alamat link-local dibatasi pada satu tautan, jadi fe80::1 bukan satu alamat yang dicetak dua kali; itu dua tetangga yang kebetulan berbagi sufiks. Indeks zona adalah cara host mengatakan mana yang dimaksud, jadi fe80::1%uplink0 dan fe80::1%uplink1 adalah tujuan berbeda bagi kernel, dan sufiks itu tidak pernah berpindah ke router jarak jauh. RFC 4007 menjelaskan model zona di baliknya, dan itulah sebabnya tabel kebijakan harus membawa perangkat pada setiap hop berikutnya link-local.
Generator konfigurasi VPN yang menyalin ID zona numerik dari satu host ke templat memperlakukan konteks lokal seolah-olah bagian dari alamat, dan berkas yang ditulisnya salah di setiap mesin yang nama atau indeks antarmukanya berbeda. Tabel kebijakan juga tidak menggabungkan dua tautan menjadi satu: VPN terutek menghantarkan paket antarjaringan, tetapi tidak membawa identitas link-local tetangga Ethernet jarak jauh melewati terowongan, sehingga lalu lintas link-local tetap di tautannya sendiri.
Hapus perangkatnya dan rute menjadi tidak dapat ditulis. ip -6 route add default via fe80::1 table 200 tidak dapat menyelesaikan gateway, dan iproute2 menolaknya dengan Error: Nexthop has invalid gateway. Tambahkan dev uplink0 dan perintahnya berhasil, karena perangkat itulah yang memaku hop berikutnya ke salah satu dari dua tetangga itu. Yang tidak dapat diberitahukan perangkat adalah apakah uplink0 tautan yang tepat untuk tabel ini, dan rute yang disalin dari host lain membawa nama antarmuka host itu bersamanya, dan dari situlah kesalahan yang sebenarnya berasal.
Kondisi satu: satu tautan atau dua di tabel
Mulailah dari apa kegunaan uplink kedua. Jika kedua tautan membawa lalu lintas yang sama dan satu bersiaga, tabel alternatif harus memuat kedua gateway dengan metrik berbeda: tujuan yang sama, satu jalur pilihan, satu pilihan kedua yang jelas. Jika uplink ada karena lalu lintas berbeda harus keluar melalui penyedia berbeda, atau karena ini terowongan belah di mana sebagian lalu lintas melewati VPN dan sisanya tetap di dalam, kedua tautan itu sama sekali tidak pantas berada di satu tabel. Keduanya pantas berada di dua tabel, yang dipilih oleh aturan, dan aturan memilih tabel, bukan terowongan: lalu lintas yang melewati ditandai sebelum dirutekan, dan tanda itulah yang mengirimnya ke tabel kedua.
Dalam kasus kedua itu aturan memutuskan kapan tabel dikonsultasikan, dan rute memutuskan ke mana paket pergi setelahnya:
ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201Tidak ada objek yang menggantikan yang lain, dan tabel yang hanya memuat default masih bisa gagal menyelesaikan gateway-nya. Jika penambahan ditolak, atau rutenya ada tetapi tidak dapat dipakai, masukkan prefiks terhubung untuk antarmuka itu ke tabel yang sama, atau tandai hop sebagai onlink saat prefiks itu dirutekan di tempat lain. Pada blok di atas, 2001:db8:100::/48 mewakili prefiks terhubung itu di uplink1, bukan tujuan sembarangan. Aturan fwmark hanya memakai tanda yang harus dipasang oleh hal lain, dari aturan nftables atau iptables pada jalur penerusan atau dari SO_MARK pada soket, jadi blok yang disalin tanpa sumber tanda tidak cocok dengan apa pun.
Kondisi dua: metrik tidak mendeteksi penyedia yang mati
Metrik adalah preferensi di antara rute yang ada, bukan pemeriksaan kesehatan. Saat pembawa putus, kernel menghapus rute pada perangkat itu dan default kedua mengambil alih. Saat kabel tetap tersambung dan penyedia di belakangnya mati, tidak ada yang berubah di tabel: rute pilihan terpasang, tetangga terjangkau di lapisan 2, dan paket keluar ke lubang hitam. Jika perbedaan itu penting bagi penyiapan Anda, failover harus datang dari sesuatu yang menguji jalur dan menghapus rute, entah itu daemon perutean atau skrip kecil yang menghapus dan memasang ulang entri.
Verifikasi pilihan setelah tabel dibangun, dan verifikasi seperti kernel akan melihatnya. ip -6 route get 2001:db8:100::1 menampilkan rute yang akan dipakai, termasuk perangkat dan alamat sumber yang dipilih, dan ia menghormati aturan kebijakan. Alamat sumber milik uplink yang salah adalah tanda biasa bahwa sebuah aturan cocok lebih awal dari yang Anda perkirakan.
Kondisi tiga: putuskan siapa yang memiliki persistensi
Rute yang ditambahkan dengan ip -6 route add bertahan sampai reboot atau sampai sesuatu menghapusnya. Default yang dipelajari dari iklan router membawa masa pakai dan dapat ditarik kembali oleh router, sedangkan default yang ditambahkan manual tidak pernah kedaluwarsa sendiri. Mencampur keduanya dalam satu tabel adalah cara rute permanen yang basi berakhir mengungguli rute yang baru diiklankan, jauh setelah uplink yang digambarkannya berhenti ada.
Pilih satu pemilik per tabel. Jika manajer jaringan atau daemon perutean sudah mengelola antarmuka, jelaskan rute kebijakan di sana dan biarkan kernel. Jika Anda membuat skripnya, buat skripnya idempoten dan tulis pembongkarannya pada saat yang sama, karena Anda akan membutuhkannya saat perubahan buruk pertama:
ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201Pada router yang meneruskan untuk host lain, periksa net.ipv6.conf.all.forwarding sebelum menyalahkan tabel. Dengan penerusan mati, paket yang dialamatkan ke jaringan lain tetap dibuang, tidak peduli seberapa benar tabel 201.
Catat desainnya agar orang berikutnya dapat mengauditnya
Inventaris yang hanya menyimpan fe80::1 membuang bidang yang penting. Catat tujuan, hop berikutnya, perangkat, tabel, dan metrik secara bersamaan, ditambah dari mana setiap rute berasal: diiklankan, dihasilkan manajer, atau statis. Saat nanti seseorang bertanya apakah uplink kedua benar-benar membawa lalu lintas, catatan itu menjawabnya tanpa dugaan.
Sebelum menyatakan tabel selesai, pastikan tetangganya dengan ip -6 neigh show dev uplink0, baca ulang ip -6 rule show untuk kecelakaan pengurutan, dan uji dengan lalu lintas yang cocok dengan aturan alih-alih ping yang mengambil rute default. Lalu matikan satu uplink dengan sengaja dan perhatikan rute mana yang dipakai kernel sebagai cadangan; jawabannya harus cocok dengan yang Anda tulis.