Satu host publik untuk VPN dan web: cara membagi peran

Satu mesin dapat memenuhi ketiga kebutuhan sekaligus: menerminasi tunnel, menjawab HTTPS, dan meneruskan antar dua LAN privat. Apakah itu masuk akal bergantung pada tiga hal yang dapat Anda putuskan di atas kertas: siapa pemilik alamat publik, siapa pemilik setiap pasangan port dan protokol, dan proses mana yang diizinkan meneruskan paket. Jika ketiganya benar, host bersama itu biasa saja. Jika salah, Anda akan menghabiskan akhir pekan dengan layanan yang mulai bersih dan tidak pernah menjawab.

Yang berikut adalah prosedur keputusan, bukan lembar pembangunan. Setiap langkah berakhir dengan pemeriksaan yang membuktikan peran yang baru Anda tambahkan benar-benar terisolasi.

Pilih pemilik alamat sebelum port

Titik akhir tunnel dan server web dapat berbagi kernel; berbagi satu alamat, port, dan protokol pada saat yang sama adalah yang gagal. WireGuard biasanya memakai UDP 51820, OpenVPN memakai UDP 1194 atau TCP 443, dan server web memakai TCP 443. Pasangan yang menyakitkan adalah OpenVPN di atas TCP 443 di samping HTTPS, karena keduanya menginginkan socket yang sama dan kernel memberikannya kepada yang mengikat lebih dulu. Hanya demultiplekser di depan, seperti sslh atau proksi yang paham TLS, yang membiarkan keduanya berbagi port itu, dan itu menambah komponen yang kegagalannya tampak persis seperti masalah firewall.

Lihat para pemilik sebelum mengubah apa pun: ss -lntup mencetak alamat lokal, port, dan proses setiap socket yang mendengarkan. Dua baris yang menunjukkan 0.0.0.0:443 berarti layanan kedua tidak pernah mengikat, seceria apa pun skrip init-nya. Jembatan juga memindahkan pemilik. Ketika eth0 bergabung dengan br0, IP berpindah ke br0 dan setiap aturan firewall yang menyebut eth0 berhenti cocok, jadi ikat layanan di jembatan dan konfirmasi dengan ip -br addr.

Aturan kepemilikan yang sama menjelaskan kejutan yang muncul pada mesin virtual. Server tunnel yang berjalan di dalam tamu pada LAN yang sama mempertahankan alamat tamu, sehingga koneksi yang diarahkan ke alamat host itu sendiri tetap tinggal di host dan tunnel tamu tidak pernah melihatnya, apa pun yang dikatakan profil klien.

Rutekan antar dua LAN atau NAT satu sisi

Dua LAN yang tidak dapat saling melihat dapat masing-masing menghubungi host publik, yang lalu meneruskan antar tunnel. Desain terutekan itu membutuhkan tiga hal: penerusan aktif, rute menuju setiap prefiks jauh, dan kebijakan penerusan yang meloloskan transit. sysctl -w net.ipv4.ip_forward=1 mencakup yang pertama, ip route add 10.20.0.0/24 dev wg1 yang kedua, dan baris nftables seperti nft add rule inet filter forward iifname "wg0" oifname "wg1" accept yang ketiga.

NAT sumber lebih mudah dipasang dan lebih sulit di-debug. Masquerading menulis ulang alamat klien, sehingga sisi jauh melihat hub alih-alih host sebenarnya, dan aturan akses serta log-nya berhenti berguna untuk atribusi. Ketika kedua jaringan milik Anda, rutekan. Ketika satu sisi milik pihak ketiga yang tidak akan menambahkan rute balik, NAT adalah opsi yang terkirim minggu ini. Bagaimanapun, tuliskan rencana alamat, karena dua /24 yang tumpang tindih tidak dapat dirutekan oleh konfigurasi apa pun.

Tidak ada yang menghalangi kotak yang sama menerminasi tunnel masuk hanya karena kotak itu menjadi pintu keluar internet bagi sebuah laptop. Hanya alamat yang tumpang tindih yang menghalangi, dan itulah sebabnya rencana alamat adalah dokumen yang penting.

Uji pemisahan saat dua peran dihentikan

Uji yang berguna adalah pengurangan: hentikan dua peran dan pastikan yang ketiga masih menjawab. Permintaan web harus selesai saat layanan tunnel mati, dan jabat tangan tunnel harus selesai saat server web dihentikan. Jika keduanya hanya bekerja saat semuanya berjalan, Anda punya ketergantungan tak sengaja, seperti tabel firewall bersama, rute tersesat, atau nama yang menunjuk ke alamat yang salah.

Tiga perintah membuat uji itu konkret. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ membuktikan pendengar lokal menjawab tanpa DNS eksternal, wg show di klien membuktikan jabat tangan selesai, dan tcpdump -ni any port 51820 di hub memisahkan masalah perutean dari masalah kunci. Jabat tangan yang tidak pernah muncul di tangkapan mati sebelum host: firewall penyedia, alamat publik yang salah, atau aturan NAT di jalan.

Ulangi pengurangan untuk LAN yang diteruskan. Dengan satu peer terputus, ping melintasi hub harus gagal; setelah tersambung lagi, ping harus pulih tanpa menyentuh aturan. Ping yang pulih hanya setelah tunnel dijalankan ulang menunjuk ke kebijakan, bukan keterjangkauan, dan itu perbaikan yang berbeda.

Jaga kumpulan aturan tetap terbaca saat Anda mengurangi peran. nft list ruleset harus menunjukkan satu aturan terima per arah yang benar-benar Anda butuhkan, dan rantai penerusan yang menerima semuanya bukan pemisahan, itu demo yang berfungsi.

Jalur akses hanya IPv6 dan layanan IPv4

Sebagian jalur akses hanya memberi keterjangkauan IPv6, dan layanan tetap harus diterbitkan lewat IPv4. Tunnel itu sendiri berjalan lewat keluarga yang masih melewatkan lalu lintas, sementara layanan yang diterbitkan duduk di alamat di dalam tunnel. Itu membalik asumsi biasa dan diam-diam merusak pemantauan: aturan firewall atau pemeriksaan waktu aktif yang ditulis untuk jalur IPv4 kini mengawasi antarmuka yang tidak membawa apa pun.

Uji setiap keluarga sendiri-sendiri dengan curl -4 dan curl -6, karena satu permintaan yang berhasil tidak mengatakan apa pun tentang jalur yang tidak Anda coba. Kepemilikan port tidak berubah antar keluarga, tetapi pendengarnya berubah: ss -lntup mendaftar socket IPv4 dan IPv6 sebagai baris terpisah, dan 0.0.0.0:443 tidak mencakup [::]:443 kecuali proses meminta socket dual-stack.

Layanan yang menjawab pada satu keluarga dan menolak pada keluarga lain biasanya masalah pendengar, bukan perutean. Sebelum menyebut desain selesai, pastikan setiap peran memiliki alamat atau port sendiri, penerusan aktif dan diizinkan, dan setiap peran masih menjawab saat dua lainnya dihentikan.