Terowong masih hidup, laluan hilang: memisahkan dua kegagalan VPN

Satu hos menjadi tidak dapat dicapai sementara antara muka terowong masih melaporkan dirinya sebagai terbentuk, dan kedua-dua pemerhatian itu tidak bercanggah. Sesuatu telah membuang laluan yang digunakan oleh trafik: jiran menarik balik awalannya, laluan statik yang dipantau telah dikeluarkan, atau laluan lain menjadi lebih digemari. Persatuan keselamatan boleh kekal sihat sepenuhnya dalam ketiga-tiga kes. Memisahkan peristiwa bermakna bertanya lapisan mana yang berubah dahulu, bukan sama ada VPN gagal.

Tiga peringkat yang kelihatan seperti satu peristiwa

Keputusan penghalaan mempunyai tiga peringkat. Awalan diterima, dipilih sebagai terbaik, dan dipasang dalam jadual penghantaran. Setiap peringkat boleh gagal sendiri, dan kegagalan kelihatan sama dari sisi aplikasi. Awalan yang dipelajari tetapi kalah dalam pemilihan tidak dapat dibezakan daripada yang tidak pernah tiba apabila satu-satunya bukti yang anda lihat ialah jadual penghantaran.

Sebab itu soalan pertama ialah peringkat mana yang rosak, bukan protokol mana yang bersalah. Jawapannya menentukan siapa pemilik insiden dan alat mana yang digunakan oleh pemeriksaan seterusnya.

Baca laluan yang dipasang dahulu

Tanya kernel ke mana trafik ke destinasi yang gagal sebenarnya pergi. ip route get mencetak lompatan seterusnya, antara muka dan alamat sumber yang akan digunakan oleh kernel, dan ia menjawab untuk satu destinasi dan bukan untuk seluruh jadual. Jika jawapan menyebut terowong, jadual penghantaran masih percaya laluan itu wujud dan masalahnya terletak di atasnya.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Jawapan «unreachable» bermaksud tiada laluan yang dipasang langsung, yang menunjuk kepada penarikan balik atau pemasangan yang hilang. Jawapan yang menyebut antara muka fizikal bermaksud trafik meninggalkan terowong tanpa sesiapa memutuskannya, dan pemeriksaan seterusnya ialah keutamaan yang menang. Jawapan yang menyebut terowong sementara paket terus hilang menunjuk lebih jauh di laluan, kepada penapisan atau ke sisi jauh.

Kemudian lihat pandangan protokol itu sendiri

Daemon penghalaan menyimpan lebih daripada satu jadual, dan perbandingan yang menarik ialah antaranya. Untuk BGP, keadaan sesi jiran, pengumuman yang diterima dan laluan yang dipasang ialah tiga bukti berasingan. Awalan boleh duduk dalam jadual yang diterima dan tidak pernah sampai ke kernel kerana laluan dengan jarak pentadbiran lebih pendek menang. Periksa ketiga-tiganya sebelum membuat kesimpulan bahawa pihak lain berhenti mengumumkan.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Ringkasan memberitahu anda sama ada sesi terbentuk, paparan setiap awalan memberitahu sama ada awalan diterima, dan carian kernel memberitahu sama ada ia dipasang. Membacanya dalam urutan itu menghalang getaran sesi daripada disalah anggap sebagai penarikan balik, dan penarikan balik daripada disalah anggap sebagai penolakan dasar.

Apabila jam tidak bersetuju

Letakkan log terowong, log penghalaan dan kegagalan aplikasi pertama pada satu garis masa menggunakan zon waktu sebenar mereka. Jika kehilangan jiran datang dahulu, terowong menjatuhkan laluan bersamanya. Jika penarikan balik datang dahulu, penghalaan berubah dan terowong bertindak balas selepas itu. Itu insiden berbeza dengan pemilik berbeza, dan urutannya ialah keseluruhan penemuan.

Satu minit sisihan jam sudah cukup untuk membalikkan kesimpulan itu, jadi sahkan zon waktu dan offset sebelum mempercayai urutannya. Peranti yang merekod dalam waktu tempatan tanpa offset ialah sumber biasa garis masa yang yakin tetapi salah.

Pemulihan tanpa gelung

Selepas penarikan balik, dua laluan boleh layak: yang dipilih oleh protokol dan yang anda sematkan dengan tangan. Hanya yang pertama ialah keputusan yang rangkaian terus ambil untuk anda, sebab itu laluan manual ialah penyelesaian sementara dan bukan pelan pemulihan. Pengumuman alternatif juga tidak mengekalkan keadaan firewall atau NAT untuk sesi yang sudah terbentuk, jadi aliran baharu mungkin berfungsi sementara yang asal kekal rosak. Sahkan sandaran mana yang patut menjadi aktif dan sama ada tapak jauh akan menerima laluan balik melaluinya.

Jangan pasang penggantian statik kekal sebelum anda memahami mengapa penarikan balik berlaku. Jalan pintas itu boleh menyematkan trafik pada laluan yang gagal atau senyap memintas dasar penghalaan yang disengajakan, dan ia mengebumikan punca asal di bawah konfigurasi baharu. Uji semula aplikasi setelah laluan dipulihkan, dan sahkan awalan yang dipilih mempunyai laluan data yang berfungsi dan bukan sekadar entri dalam jadual.