Klien hilir di balik VPN hulu: rute atau NAT?

Satu gateway menjalankan WireGuard untuk perangkat Anda sendiri dan klien OpenVPN ke jaringan orang lain. Penerusan antara dua antarmuka dalam berfungsi, dan mudah menyimpulkan bahwa subnet hilir kini menjadi bagian dari layanan hulu. Tidak demikian. Rute yang ditarik klien memberi tahu gateway Anda ke mana mengirim permintaan; itu tidak mengatakan apa pun tentang bagaimana jaringan jauh mengembalikan lalu lintas ke perangkat yang belum pernah didengarnya. Pilih model pengembalian yang benar-benar didukung hulu sebelum Anda menambahkan satu aturan pun.

Putuskan model pengembalian sebelum Anda menyentuh perutean

Dalam panduan ini, klien hilir memakai 10.90.0.0/24, alamat tunnel hulu yang diberikan ke gateway adalah 10.80.0.6, dan sumber daya jauh yang disetujui adalah 172.20.0.30. Dua model cocok dengan bentuk itu: pertahankan sumber hilir dan buat sisi jauh merutekannya, atau terjemahkan sumber ke alamat tunnel gateway itu sendiri. Semua yang mengikuti keputusan ini bersifat mekanis, dan keputusan itu sendiri membutuhkan pemilik layanan. Satu baris di atas adalah kesepakatan perutean dengan sisi jauh; yang lain adalah perubahan kebijakan lokal yang bisa Anda lakukan sendiri. Mencampuradukkan keduanya adalah yang mengubah perubahan sepuluh menit menjadi negosiasi.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Pilih satu baris dan berpegang padanya. Baris-baris itu alternatif, bukan langkah, dan mencampurnya menghasilkan desain yang tidak bisa dijelaskan siapa pun saat tinjauan.

Pemeliharaan sumber dengan rute

Sisi jauh menerima permintaan dari alamat hilir, jadi ia membutuhkan rute yang didukung dan kepemilikan peer untuk subnet itu, plus otorisasi untuk menerimanya. Itu pengaturan jauh, dan tidak ada rute Linux lokal yang membuatnya. Mintalah secara eksplisit dan tertulis, dengan prefiks dan peer tunnel yang akan membawanya, dan perkirakan jawabannya bergantung pada apakah layanan itu mendukung pengaturan situs-ke-situs sama sekali.

Jika jawabannya ya, konfigurasi lokalnya kecil: penerusan aktif, allowed-ips peer WireGuard yang mencakup rentang hilir, dan kebijakan firewall yang mengizinkan penyeberangan di kedua arah.

Terjemahan sumber yang disengaja

Jika layanan hanya mengembalikan lalu lintas ke alamat klien yang terhubung, terjemahkan sumber ke alamat itu saat keluar dan pertahankan status conntrack yang membalikkannya untuk balasan. Batasi aturan ke sumber hilir yang dimaksud, tujuan jauh yang dimaksud, dan antarmuka hulu. Aturan yang menerjemahkan semua yang keluar dari setiap antarmuka adalah kebijakan yang jauh lebih besar daripada kebutuhan ini, dan itu akan mengejutkan Anda nanti.

IPv6 membutuhkan desainnya sendiri; menyalin baris masquerade IPv4 bukanlah arsitektur. Uji jalur yang diterjemahkan dengan koneksi baru, bukan yang di-cache.

Jalur data lokal tetap harus berfungsi

Terjemahan tidak menghilangkan pekerjaan lokal: gateway masih membutuhkan rute untuk tujuan hilir, kepemilikan sumber peer WireGuard yang benar, penerusan aktif, dan kebijakan firewall sempit antar antarmuka. Permintaan yang dibuat di gateway itu sendiri tidak melatih satu pun dari izin tersebut, itulah sebabnya uji lokal di gateway lolos sementara perangkat hilir tetap gagal.

Uji dari perangkat hilir yang sebenarnya, bukan dari gateway. Alamat sumber adalah inti seluruh latihan ini.

Satu sumber berarti satu identitas sesi

Layanan jauh melihat sesi gateway yang terautentikasi dan alamatnya yang diterjemahkan, bukan autentikasi terpisah untuk setiap perangkat hilir. Jaga izin per perangkat dan identitas aplikasi tetap eksplisit, dan konfirmasikan dengan pemilik layanan bahwa gateway yang bertindak untuk beberapa perangkat memang diizinkan. Terjemahan bukan cara melewati persyaratan pendaftaran per perangkat; jika layanan mewajibkan setiap perangkat mendaftar, gunakan model itu atau negosiasikan pengaturan situs-ke-situs.

Tulis konfirmasi itu di runbook di samping aturannya, karena peninjau berikutnya akan bertanya apakah desain itu disetujui atau hanya nyaman.

Tentukan keadaan terputus, lalu uji tiga permintaan

Putuskan apa yang terjadi ketika tunnel hulu putus. Lalu lintas jauh yang diotorisasi tidak boleh diam-diam mengikuti cadangan WAN biasa di tempat itu dilarang, jadi kebijakan firewall yang mengizinkan penyeberangan juga harus gagal tertutup. Lalu uji tiga kasus dari perangkat hilir sungguhan: permintaan yang diizinkan dan berhasil, permintaan yang tidak diizinkan dan gagal, serta kegagalan hulu yang menghentikan yang diizinkan.

Catat pembatalan dalam satu baris per aturan, agar perubahan dapat dibatalkan tanpa merekonstruksi maksudnya.