Dua lompatan VPN di satu Pi: rute mana membawa peer mana

Dua alamat terowongan di satu papan kecil tampak seperti kesalahan, dan reaksinya adalah menghapus salah satunya. Reaksi itu merusak hal yang seharusnya dirapikannya. Host yang membawa dua lompatan menyimpan satu alamat per sambungan, dan setiap alamat dipilih oleh rute yang berbeda. Pertanyaan yang layak diajukan adalah rute mana memilih pembawa mana untuk tujuan mana, bukan berapa banyak alamat yang ada.

Tiga tujuan yang membutuhkan pembawa berbeda

Rantai dua lompatan adalah tiga kelas tujuan yang bertumpuk, dan masing-masing dibawa oleh sambungan yang berbeda. Peer luar harus dicapai melalui tautan fisik. Peer dalam harus dicapai melalui terowongan luar. Tujuan aplikasi yang tercakup harus dicapai melalui terowongan dalam, yang transportasinya sendiri dibawa oleh yang luar.

Isi baris dengan alamat nyata pembaca sebelum menyentuh rute, karena tabel hanya berguna setelah konkret. Rantai yang berfungsi memenuhi keempat baris sekaligus, dan rantai yang setengah berfungsi biasanya memenuhi salah satunya dengan pembawa yang salah. Membaca baris yang salah sebagai kegagalan itulah yang mengubah masalah perutean menjadi seharian penyuntingan.

Alamat punya peran, bukan jumlah

Linux mengizinkan beberapa alamat pada satu antarmuka dan beberapa terowongan pada satu host, jadi jumlah tidak mengatakan apa pun tentang kebenaran. Yang penting adalah alamat mana milik sambungan mana, dan apakah rute untuk peer tertentu memilih sambungan yang Anda maksud. Tiga tampilan menjawabnya dari tiga arah, dan layak dibaca dalam urutan yang sama setiap kali.

Inventaris alamat menunjukkan apa yang ada dan sambungan mana yang memilikinya. Tabel rute menjawab pertanyaan pembawa untuk lalu lintas tujuan biasa. Tampilan kebijakan menjawabnya lagi untuk lalu lintas yang dipilih berdasarkan sumber atau tanda, yang merupakan susunan normal ketika dua klien berbagi satu host.

ip -4 addr show
ip -4 route show table all
ip rule show

Menghapus alamat karena daftarnya tampak panjang dapat menghilangkan sebagian jalur, dan menghapus rute karena tampak berlebihan melakukan hal yang sama dengan lebih diam. Keduanya tidak menghasilkan kesalahan; peer berhenti menjawab di jalur yang Anda maksud sambil tetap dapat dicapai lewat jalur lain. Aplikasi yang melaporkan alamat keluar peer dalam tidak membuktikan bahwa lalu lintas melewati terowongan luar, karena akses langsung menghasilkan pengamatan yang sama. Celah antara pengamatan dan bukti itulah sebabnya pembawa diperiksa di lapisan perutean.

Urutan aktivasi mengalahkan tidur tetap

Jika klien dalam bergantung pada alamat atau rute yang disediakan klien luar, aktivasi harus menunggu sumber daya itu, bukan penundaan. Tidur berfungsi sampai hari ketika terowongan luar lambat, lalu gagal secara berkala dengan cara yang tidak dapat direproduksi siapa pun. Pengurutan berbasis ketergantungan menghilangkan tebakan dan tidak memakan biaya selain menjelaskan ketergantungan sekali. Nama antarmuka juga bukan mekanisme pengurutan.

Kernel memberikan nama seperti tun0 dan tun1 dalam urutan pembuatan, dan urutan itu dapat berubah antar-reboot atau sambung ulang. Ikat konfigurasi ke identitas yang disediakan perkakas, atau ke nama yang Anda tetapkan dengan sengaja. Nama yang Anda pilih adalah kontrak; nama yang dipilih kernel adalah kebetulan.

Jauhkan transportasi setiap klien dari rute aplikasi klien lain, dan tepatlah tentang apa yang sebenarnya dijanjikan opsi perutean OpenVPN 2.6. Mekanisme pengalihan default yang terdokumentasi menjaga klien tetap dapat mencapai peer jauhnya sendiri melalui gateway yang sudah ada, yang memotong satu putaran rekursi tertentu. Mekanisme itu tidak menjadikan satu klien sebagai pembawa klien lain, jadi sisa rantai tetap rancangan Anda. Ketika rantai membutuhkan kebijakan alih-alih rute, tulis aturan sumber atau tanda yang eksplisit dan ujilah dengan lalu lintas yang seharusnya dicocokkannya.

Apa yang terjadi ketika lompatan luar mati

Sebelum rantai dianggap lengkap, putuskan apa yang terjadi ketika lompatan luar hilang. Transportasi klien dalam mati bersamanya, dan langkah berikutnya adalah pertanyaan kebijakan, bukan teknis: gagal, coba lagi, atau sambung ulang langsung melalui tautan fisik. Hasil ketiga itulah yang perlu dipikirkan. Ia diam-diam mengubah rancangan dua lompatan menjadi rancangan satu lompatan pada saat pengguna percaya cakupannya masih utuh.

Jika dua lompatan wajib, klien dalam harus tidak dapat membangun jalur langsung ketika yang luar hilang, dan cara mengetahuinya adalah memutus lompatan luar dan mengamati apa yang dilakukan yang dalam. Rencana cadangan yang disetujui adalah jawaban yang sah, tetapi harus ditulis, diuji, dan dikomunikasikan. Rencana cadangan yang tidak didokumentasikan siapa pun tidak dapat dibedakan dari kebocoran saat peninjauan insiden.

DNS dan keluarga alamat lainnya termasuk dalam keputusan yang sama. Pencarian yang dihasilkan secara lokal mengikuti kebijakan host itu sendiri, bukan kebijakan klien yang diteruskan, sehingga resolver yang bekerja untuk lalu lintas yang diteruskan mungkin bukan yang digunakan host itu sendiri.

Terima setiap lapisan dalam urutan Anda membangunnya

Uji dalam urutan rantai dibangun: pertama terowongan luar saja, lalu transportasi klien dalam melalui terowongan luar, lalu aplikasi melalui terowongan dalam. Setiap penerimaan harus berupa koneksi baru, bukan halaman yang sudah terbuka. Lalu putuskan dan pulihkan setiap lapisan secara terpisah dan amati apa yang dilakukan lapisan berikutnya.

Hasil rencana cadangan adalah pengamatan paling berharga di sini, dan yang tidak pernah ditampilkan halaman IP publik. Simpan jalur peer, alamat yang mereka gunakan, dan hasil itu di samping konfigurasi, karena jalur bahagia bukan bagian yang dipertanyakan kemudian.