NAT LAN lewat tun0 di gateway VPN OpenBSD

Dua engineer dengan gateway OpenBSD yang sama sering memberi Anda dua set aturan berbeda untuk mencapai jaringan jauh, dan keduanya bisa dipertahankan. Pilihan antara terjemahan sumber dan rute balik sama sekali bukan soal sintaks. Semuanya bergantung pada apa yang sudah diketahui sisi jauh tentang 192.168.88.0/24 dan apa yang perlu Anda simpan di log. Kalau salah di sini, baris nat-to akan terlihat sangat benar sementara balasan menghilang ke gateway default jauh.

Routing dan penulisan ulang menjawab pertanyaan berbeda

Tabel routing memutuskan bahwa 172.20.0.0/16 dapat dijangkau lewat tun0, dan keputusan itu diambil sebelum terjemahan pf mana pun dikonsultasikan. Terjemahan sumber kemudian mengubah header paket sehingga ujung jauh melihat alamat tunnel gateway alih-alih host LAN. Tidak ada mekanisme yang menggantikan yang lain: aturan nat tidak bisa menciptakan rute, dan rute tidak bisa meyakinkan router jauh yang belum pernah mendengar tentang subnet pribadi Anda. Ketika sisi jauh tidak punya jalur balik, balasan dibuang atau diteruskan ke gateway default-nya, dan tidak ada penyetelan aturan yang bisa memperbaikinya.

Sederhananya, penerusan menjawab ke mana lalu lintas pergi dan terjemahan menjawab dari mana ia tampak datang. Simpan keduanya di kotak mental terpisah saat Anda merancang set aturan.

Tiga kondisi yang menentukan

Ajukan tiga pertanyaan secara berurutan dan desainnya biasanya memilih sendiri. Apakah jaringan jauh punya rute statis yang menunjuk ke alamat tunnel untuk 192.168.88.0/24, atau apakah administratornya mengendalikan router di jalur itu? Jika ya, biarkan alamat LAN berjalan tanpa diubah dan lewati terjemahan sepenuhnya. Apakah Anda perlu visibilitas per klien di sisi jauh, baik untuk kebijakan akses maupun jejak audit? Jika ya, mempertahankan sumber sepadan dengan kerja routing. Apakah alamat tunnel cukup stabil untuk ditulis ke rute jauh, atau berubah di antara sambungan ulang?

Jika salah satu jawabannya tidak atau tidak diketahui, nat-to adalah pilihan pragmatis, dan juga yang bisa dibalik. Aturan terjemahan hilang dalam satu baris setelah sisi jauh menambahkan rute yang layak. Rute balik yang tidak pernah dipasang membuat Anda mengurus satu utas dukungan setiap kali seseorang bertanya mengapa tunnel hanya bekerja satu arah.

Menempatkan fragmen agar pf benar-benar menilainya

Fragmen di bawah mengasumsikan LAN adalah 192.168.88.0/24, jaringan jauh adalah 172.20.0.0/16, dan antarmuka tunnel adalah tun0. Tidak ada yang memilih hop berikutnya di dalamnya. Ia hanya menulis ulang sumber pada paket yang sudah keluar lewat tunnel.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Dua detail di baris pertama itu memikul sebagian besar beban. Tanda kurung di sekitar tun0 memberi tahu pf untuk membaca alamat antarmuka setiap kali ia membangun entri state, yang penting saat tunnel dinomori ulang setelah sambungan ulang. Kata match berarti aturan menulis ulang lalu diteruskan ke bawah, jadi aturan pass terpisah tetap harus mengizinkan aliran. Antarmuka yang disebut di baris match juga harus yang dipilih tabel routing, kalau tidak pf menilai aturan pada jalur keluar yang berbeda dari yang benar-benar diambil paket.

Jangan lupa sisi kernel. Penerusan IPv4 harus diaktifkan, dan aturan pass stateful untuk tunnel dan LAN harus ada sebelum semua ini bermakna. Bagian PF NAT di FAQ OpenBSD adalah rujukan yang tepat untuk urutan kata kunci di sini.

Verifikasi set aturan sebelum Anda memercayai lalu lintasnya

Periksa sintaks lebih dulu dengan pfctl -nf /etc/pf.conf, yang mengurai berkas tanpa memuatnya. Lalu muat kebijakannya dan baca kembali apa yang benar-benar dipegang kernel, karena aturan yang terurai bersih masih bisa tertutup atau terpasang pada antarmuka yang salah. pfctl -sn mencetak aturan terjemahan dalam bentuk termuatnya, dan pfctl -sr mencetak aturan filter menurut urutan evaluasi.

Selanjutnya amati kabelnya. Di gateway, tcpdump -ni tun0 'host 172.20.0.10' menunjukkan apakah alamat sumber yang keluar dari tunnel adalah alamat tunnel atau host LAN. netstat -rn -f inet yang cepat memastikan ke antarmuka mana tujuan tersebut diselesaikan. Begitu lalu lintas mengalir, pfctl -ss mendaftar entri state; jika suatu aliran tidak menghasilkan state, paket itu tidak pernah cocok dengan aturan yang membuatnya.

Jika sisi tunnel tampak benar dan balasan tetap tidak datang, berhenti menyunting pf. Kegagalan yang tersisa ada di router jauh, tempat balasan dikirim menuju alamat pribadi yang tidak dapat dijangkau sisi itu.

Ketika terjemahan lebih mahal daripada penghematannya

Terjemahan menyembunyikan klien, dan kadang itulah justru pertukaran yang salah. Subnet yang tumpang tindih adalah satu kasus: jika sisi jauh juga memakai 192.168.88.0/24 secara internal, menampilkan host LAN sebagai gateway membuat benturannya lebih buruk, bukan lebih baik. Kebijakan IPsec yang memilih lalu lintas berdasarkan pasangan alamat adalah kasus lain, karena basis data kebijakan keamanan dicocokkan sebelum terjemahan dan tidak pernah melihat paket yang Anda tulis ulang. Penerapan apa pun yang menagih, membatasi, atau mengaudit per pengguna juga kehilangan identitas yang dibutuhkannya begitu sumber menyusut menjadi satu alamat.

Turunan pf portabel adalah jebakan tersendiri. Produk yang menghasilkan berkas aturannya sendiri mengharapkan NAT dikonfigurasi lewat antarmuka mereka, dan fragmen yang disunting tangan akan ditimpa pada pemuatan ulang berikutnya. Set aturan yang disalin dari panduan yang ditulis sebelum kata kunci match ada tidak akan dimuat pada kernel sekarang, jadi porting sintaksnya dan baca galatnya alih-alih menebak.

Aturan keputusan yang bertahan saat berhadapan dengan jaringan nyata itu singkat: pasang rute balik bila Anda bisa, terjemahkan bila tidak bisa, dan catat kondisi mana dari ketiganya yang membuat Anda memilih. Catatan itu menghemat satu sore bagi orang berikutnya.