VPN Bersarang: Tunnel Mana yang Membawa Koneksi Luar?

Dua klien VPN yang berjalan bersamaan tidak menghasilkan tunnel bersarang; keduanya menghasilkan dua tunnel dan perdebatan soal perutean. Tunnel bersarang ada ketika koneksi klien dalam ke servernya sendiri dibawa oleh tunnel luar, dan itu adalah susunan yang dibangun dengan sengaja. Kalau benar, server dalam melihat alamat server luar; kalau salah, satu klien diam-diam menyambung ulang melewati yang lain. Tiga kondisi menentukan apakah penyarangan itu nyata atau kebetulan.

Tiga kondisi menentukan penyarangan

Yang pertama adalah titik akhir mana yang membutuhkan jalur mana. Sebutkan alamat server dalam, sebutkan alamat server luar, dan nyatakan dengan tegas bahwa server dalam hanya dapat dijangkau melalui tunnel luar. Semua hal lain mengikuti kalimat itu, termasuk rute mana berada di tabel mana.

Yang kedua adalah apakah Anda dapat melihat jalur di setiap lapisan. Jika Anda tidak dapat menanyakan ke kernel rute mana yang akan dipakai tujuan tertentu, Anda menyimpulkan rantai dari IP keluar terakhir, dan itulah bukti yang tidak dapat membedakan penyarangan dari kebetulan.

Yang ketiga adalah apa yang terjadi ketika tunnel luar jatuh. Tunnel dalam dapat berhenti bersamanya, menyambung ulang lewat jaringan biasa, atau tetap terblokir sampai jalur luar kembali, dan ketiganya adalah kebijakan yang dapat dipertahankan. Ketiganya bukan kebijakan yang sama, dan perilaku bawaan sebagian besar klien adalah yang kedua. Klien yang menyambung ulang titik akhirnya lewat jaringan fisik sambil menampilkan koneksi yang sehat adalah cara paling umum sebuah rantai yang diniatkan diam-diam menjadi dua tunnel yang tidak berhubungan.

Kondisi pertama: titik akhir mana membutuhkan jalur mana

ip route get 203.0.113.10 menjawab pertanyaan itu secara langsung: perintah ini mencetak rute, alamat sumber, dan antarmuka yang akan dipakai kernel untuk tujuan itu saat ini.

Jalankan untuk server dalam sebelum klien dalam mulai dan sekali lagi setelahnya, lalu bandingkan. Jika jawabannya berubah dari antarmuka fisik ke antarmuka tunnel luar, penyarangan itu nyata pada saat itu. Jika tidak berubah, klien dalam menyambung langsung, apa pun kata panel. Ulangi untuk alamat server luar, yang tetap harus diselesaikan lewat antarmuka fisik, karena rute yang menangkap kedua titik akhir secara rekursif adalah kegagalan yang mengeluarkan mesin dari jaringan sepenuhnya.

Kondisi kedua: periksa jalur di setiap lapisan

Pemilihan rute lebih dari sekadar tabel utama pada klien modern. Aturan kebijakan dapat mengirim paket bertanda ke tabel lain, klien dapat mengikat soketnya ke antarmuka, dan kontainer atau namespace punya tabel sendiri. ip rule dan ip route show table all adalah cara mengetahui mekanisme mana yang sedang berlaku.

Klien yang memasang SO_MARK pada soketnya sendiri, atau dikonfigurasi untuk terikat ke perangkat tertentu, melewati rute bawaan yang Anda kira sudah diatur. Itu fitur, bukan cacat, dan artinya satu-satunya pemeriksaan yang andal adalah yang berjalan di namespace yang sama dengan klien. Jika klien berjalan di kontainer, jalankan pemeriksaan di dalam kontainer itu, bukan di host.

Kondisi ketiga: apa yang terjadi ketika tunnel luar jatuh

Perilaku saat gagal menuntut keputusan, bukan nilai bawaan. Tuliskan apa yang harus terjadi pada tunnel dalam ketika tunnel luar hilang, lalu buat klien melakukannya.

Pilihannya konkret. Menghentikan klien dalam saat jalur luar hilang memberi rantai yang bersih dan gangguan yang jelas. Membiarkannya menyambung langsung memberi ketersediaan dan diam-diam menghapus sifat yang menjadi alasan rantai itu dibangun. Memblokir sampai jalur luar kembali adalah pilihan paling ketat dan paling merepotkan untuk dioperasikan, karena setiap goyangan tunnel luar menjadi insiden yang terlihat.

Uji ketiganya dengan lalu lintas tidak berbahaya dan kegagalan tunnel luar yang disengaja, karena membaca konfigurasi tidak akan memberi tahu Anda mana yang Anda punya. Matikan tunnel luar, amati apa yang dilakukan klien dalam, dan periksa rute lagi selama tunnel itu mati. Lalu kembalikan tunnel luar dan pastikan rantai terbentuk lagi alih-alih membiarkan klien dalam di jalur langsung yang ia pilih sementara itu.

Apa yang tidak diberikan rantai itu

Lapisan tambahan menambah titik akhir, kunci, dan mode kegagalan; lapisan itu tidak menambah jaminan anonimitas dan tidak membuat operator luar tidak dapat melihat bahwa ada tunnel. Setiap klaim tentang apa yang dilindungi penyarangan harus menyebut pengamat yang dilindunginya.

Hasilnya adalah dokumen singkat, bukan koneksi yang berfungsi: titik akhir mana memakai jalur mana, apa yang terjadi saat kegagalan luar, dan tiga perintah yang menunjukkan keadaan saat ini. Dokumentasi strongSwan tentang penerusan adalah rujukan berguna tentang bagaimana lalu lintas tunnel diteruskan antar antarmuka di host Linux. Jalankan lagi pemeriksaan setelah setiap pembaruan klien, karena nilai bawaan yang menghasilkan rantai Anda bukanlah kontrak. Tunnel bersarang yang tidak dapat Anda periksa adalah desas-desus dengan lampu status.