Entri VPN WAN kedua gagal sementara yang utama masih berfungsi

Tunnel utama tetap aktif, pengguna terus bekerja, dan sirkuit ISP kedua menganggur apa pun yang Anda ubah. Anda menerbitkan alamat untuk sirkuit cadangan, mengarahkan nama ke sana, mungkin menambahkan entri cadangan ke klien, dan klien entah tidak pernah mencobanya atau berhasil autentikasi lalu mati. Dalam kasus yang saya telusuri, fitur failover biasanya baik-baik saja; yang hilang adalah salah satu dari lima hal yang membuat sebuah entri bisa dipakai. Sebuah nama bisa resolve ke alamat cadangan sementara tidak ada yang mendengarkan di antarmuka itu, dan listener bisa menerima koneksi sementara balasannya keluar lewat jalur utama. Perlakukan setiap WAN sebagai entri terpisah dengan kontraknya sendiri dan kegagalan berhenti terlihat seperti bug klien.

Setiap WAN memerlukan kontrak entrinya sendiri

Catat lima bidang per WAN: nama dan alamat publik, transport dan port, antarmuka atau konteks yang mengakhirinya, identitas peer yang harus disajikan, dan dari mana balasan keluar. Dua sirkuit berarti dua set lengkap. Jika set kedua tidak punya antarmuka pengakhir atau jalur balik, Anda tidak punya entri cadangan; Anda punya catatan DNS yang menggambarkan niat.

Perangkat dan versinya juga harus mendukung susunan ini. Catatan DNS tidak bisa membuka layanan di antarmuka lain, dan di banyak platform listener dikonfigurasi per alamat, bukan per perangkat. IPsec berbasis antarmuka pada ASA mengikat peta kripto dan grup tunnel ke antarmuka luar, jadi uplink kedua memerlukan kebijakan di tempat paket itu benar-benar tiba. Desain berbasis rute berperilaku berbeda: listener bisa terikat ke setiap alamat atau ke satu alamat bernama, dan pilihan itu menentukan apakah ISP B bisa menjawab sama sekali.

Pastikan WAN kedua benar-benar menjawab

Uji dari luar kedua sirkuit, bukan dari mesin di belakang gateway, dan uji nama persis yang dipakai profil klien. Untuk listener TLS, pemeriksaan cepatnya adalah openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts yang dijalankan dari host di luar jaringan Anda. Anda ingin handshake yang selesai dengan rantai yang cocok dengan nama di profil, bukan sekadar port TCP yang menerima koneksi.

RFC 9525 menjelaskan apa yang diperiksa klien: identitas yang hendak dicapai, dibandingkan dengan sertifikat yang disajikan layanan. Entri kedua yang mengembalikan sertifikat entri utama, atau sertifikat default yang tidak mencantumkan salah satu nama, gagal pada uji ini meski port terbuka dan firewall mengizinkannya.

Dua pola menjelaskan sebagian besar kegagalan di sini. Koneksi yang menggantung biasanya berarti tidak ada listener di antarmuka itu, aturan akses yang hanya mengizinkan subnet utama, atau perangkat operator di depan sirkuit kedua yang menjatuhkan port. Handshake yang berakhir dengan identitas salah biasanya berarti trustpoint lain, host virtual default, atau konfigurasi yang disalin dari yang utama tanpa menyesuaikan identitas.

Ikuti balasannya, bukan hanya permintaannya

WAN kedua biasanya rusak di jalur balik. Permintaan datang lewat ISP B, perangkat menjawab, dan balasan keluar lewat rute default di ISP A dengan alamat sumber yang tidak pernah diminta klien. Terjemahan stateful memperburuknya: jika pemetaan dibuat untuk antarmuka utama, paket yang kembali melewatkan terjemahan atau membawa sumber yang dibuang firewall klien. Penyedia juga membuang alamat sumber yang bukan milik sirkuit yang mereka berikan, karena itu ini tampak seperti lubang hitam satu arah alih-alih kesalahan protokol yang bersih.

Periksa keputusan routing untuk lalu lintas yang berasal dari entri kedua. Balasan harus keluar dari antarmuka tempat permintaan tiba, atau setidaknya membawa alamat yang diterima sisi jauh sebagai milik jalur itu. Pada platform routing berbasis kebijakan itu berarti aturan yang dikunci ke antarmuka masuk atau sumber yang diterjemahkan, ditambah pernyataan terjemahan yang terikat ke setiap antarmuka luar. Tangkap di kedua antarmuka sekaligus saat klien terhubung; SYN yang tiba di ISP B dengan SYN-ACK yang keluar di ISP A menyelesaikan pertanyaan dalam satu kali jalan.

Beri klien cara mempelajari entri kedua

Failover adalah keputusan di sisi klien, dan setiap keluarga klien mempelajari alternatif dengan cara berbeda. Pada ASA, daftar server cadangan dikirim lewat atribut webvpn kebijakan grup, sementara klien lain mengharapkan daftar di dalam profil atau profil kedua manual yang dipilih pengguna. Panduan kebijakan koneksi Cisco menjelaskan informasi cadangan yang dikonfigurasi di klien maupun yang disediakan gateway, dan detail khusus protokol itu tidak boleh digeneralisasi ke setiap klien atau mode tunnel. Pastikan mekanisme mana yang diterapkan klien yang dipakai sebelum membangun entri kedua di sekitar mekanisme yang salah.

Apa pun mekanismenya, klien harus bisa me-resolve nama alternatif sebelum kehilangan jalur utama. Ketergantungan itulah yang sering terlewat: jika nama cadangan dijawab oleh resolver yang hanya bisa dijangkau lewat tunnel yang baru saja gagal, fallback bahkan tidak bisa mulai. Terbitkan nama kedua di resolver yang menjawab secara lokal atau lewat internet. Harapkan autentikasi baru dan sesi aplikasi baru setelah perpindahan, karena failover klien bukan failover stateful dan sesi berumur panjang tidak selamat.

Satu alamat pada dua penyedia adalah produk lain

Menjaga satu alamat publik tetap terjangkau lewat kedua sirkuit adalah layanan routing, bukan kotak centang di VPN. Ini memerlukan ruang alamat yang bersedia dibawa kedua penyedia, diumumkan dengan cara yang diterima jaringan mereka, dan itulah yang diberikan multihoming dengan ruang independen penyedia dan BGP. Menetapkan alamat ISP A ke antarmuka ISP B tidak sampai ke sana; paket tiba di jaringan yang tidak pernah mengumumkan prefiks itu dan dibuang di hulu.

Anda tidak memerlukan semua itu untuk menerbitkan dua entri. Jika klien bisa menyimpan dua nama dan failover di antaranya, dua entri independen sudah cukup, dan Anda menghindari nomor AS, kesepakatan peering, dan prefiks yang harus diterima di mana-mana. Pertimbangkan opsi alamat portabel hanya ketika Anda benar-benar perlu satu titik masuk stabil yang tidak bisa dikonfigurasi ulang klien untuk menggantikannya, atau ketika failover berbasis DNS dengan penundaan TTL-nya terlalu lambat untuk gangguan yang Anda rancang.

Apa yang harus diperiksa berikutnya

Bekerjalah keluar dari entri yang gagal dalam urutan ini: apakah alamat kedua menjawab dari luar, apakah ia menyajikan identitas yang diharapkan klien, apakah balasan keluar lewat jalur tempat permintaan tiba, dan apakah klien bisa mempelajari nama sebelum membutuhkannya. Di mana jawabannya tidak, perbaiki lapisan itu dan uji ulang dengan profil yang dipakai, bukan host uji, karena handshake dari laboratorium membuktikan lebih sedikit daripada koneksi selesai dari klien sungguhan.

Simpan catatan singkat per WAN, dengan alamat, port, antarmuka pengakhir, nama sertifikat, jalur balik, dan aturan terjemahan, dan periksa ulang setiap kali sirkuit, perangkat NAT, atau versi klien berubah. Jalur cadangan yang menganggur membusuk diam-diam: tidak ada yang memperingatkan tentang entri yang tidak dipakai siapa pun sampai hari semua orang bergantung padanya.