Rutekan antar LAN privat sebelum menambah NAT lain

Dua firewall internal, satu segmen transit privat, dan permintaan agar beberapa host di setiap LAN dapat berbicara dengan host di LAN lain. Refleksnya adalah memasang VPN atau menambahkan lapisan NAT kedua, dan kedua refleks itu berbiaya lebih besar daripada masalahnya. Routing biasa sudah cukup bila tiga syarat terpenuhi: rentang alamat tidak tumpang tindih, kedua sisi dapat mengembalikan lalu lintas ke LAN lain, dan segmen transit sudah cukup dipercaya untuk data tersebut. Periksa ketiganya sebelum merancang apa pun, karena masing-masing mengubah jawabannya.

Tiga syarat yang menentukan desain

Syarat pertama adalah ruang alamat. Jika kedua LAN memakai blok RFC 1918 yang sama, routing tidak dapat membedakannya dan penerjemahan menjadi tak terhindarkan, bukan pilihan. Syarat kedua adalah jalur balik: rute dari A ke B tidak berguna kecuali B juga tahu cara mencapai LAN milik A, dan pengetahuan asimetris adalah alasan paling umum sebuah desain ber-routing diam-diam membuang balasan.

Syarat ketiga adalah kepercayaan. Routing memindahkan paket; ia tidak melindunginya. Segmen transit privat di dalam satu gedung berbeda dari penyerahan ke penyedia atau tautan yang melintasi tulang punggung kampus bersama. Jika segmen itu tidak dipercaya, jawabannya adalah tunnel antara kedua firewall, dan rencana routing di bawah tetap berlaku di dalamnya.

Hanya bila ketiganya menunjuk arah yang sama desain sederhana menang. Bila salah satunya gagal, perbaiki syarat itu secara eksplisit alih-alih menutupinya dengan penerjemahan, karena NAT menyembunyikan kegagalan, bukan menyelesaikannya.

Bangun rencana rute di jaringan transit

Beri setiap firewall sebuah alamat pada segmen bersama dan tambahkan satu rute spesifik untuk setiap LAN jauh. Tidak ada hal lain dalam konfigurasi yang ada yang perlu bergeser, dan khususnya rute default internet harus tetap persis di tempatnya. Mengganti rute default dengan firewall peer akan mengirim setiap tujuan yang tidak terkait melewati transit, yang merupakan perubahan jauh lebih besar daripada yang diminta. Dokumentasi pfSense tentang routing statis menjelaskan model rute-plus-gateway yang sama untuk platform itu, dan kendali setaranya ada pada firewall apa pun yang benar-benar Anda jalankan.

Firewall A melayani 10.30.0.0/24 dan firewall B melayani 10.40.0.0/24, dengan kedua alamat transit berada di 192.0.2.0/24. Setiap host LAN mempertahankan firewall lokalnya sebagai gateway, sehingga satu-satunya keadaan baru adalah satu rute di masing-masing sisi. Pada firewall berbasis Linux rencana yang sama terlihat seperti ini, dan penerusan harus diaktifkan atau rute akan teresolusi sementara paket dibuang.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Pisahkan penyaringan dari penerjemahan

Routing dan kebijakan adalah kendali yang berbeda, dan pada yang kedua sebagian besar desain ber-routing benar-benar gagal. Izinkan sumber, tujuan, dan layanan tertentu di batas masuk yang benar-benar dilalui paket, dan ingat bahwa label antarmuka seperti WAN adalah nama, bukan pernyataan tentang kepercayaan. Port transit yang membawa lalu lintas privat bisa saja masih memiliki pemblokiran alamat privat yang aktif secara default.

Lalu lihat penerjemahan keluar sebelum menyimpulkan tidak ada NAT. Aturan keluar otomatis dapat menulis ulang lalu lintas yang tidak pernah dimaksudkan untuk diterjemahkan, dan itu menghancurkan alamat sumber yang dibutuhkan sisi jauh untuk kebijakan serta lognya sendiri. Pastikan aliran yang dipilih mempertahankan alamat aslinya, dan biarkan aturan penerjemahan internet untuk lalu lintas yang masih membutuhkannya.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Ketika NAT adalah jawaban yang jujur

Penerjemahan berhak mendapat tempatnya ketika rentang alamat benar-benar tumpang tindih dan penomoran ulang tidak tersedia, atau ketika kebijakan menuntut satu sisi melihat satu alamat alih-alih sebuah subnet. Dalam kasus itu pemetaan satu-ke-satu atau terbatas port yang disengaja adalah keputusan desain dengan konsekuensi yang diketahui, bukan akal-akalan.

Konsekuensi yang harus dikatakan terang-terangan adalah sisi jauh tidak lagi dapat melihat atau menyaring sumber individual. Log menyusut ke alamat penerjemah, kebijakan per host berhenti bekerja, dan pemecahan masalah menjadi perburuan host internal mana yang memiliki aliran pada saat tertentu. Jika semua itu tidak penting bagi lalu lintas yang dimaksud, NAT baik-baik saja.

Ketika transit itu sendiri adalah asumsi yang salah

Jika segmen bersama melintasi penyedia, fabric switching bersama, atau jalur apa pun tempat pihak lain dapat membaca lalu lintas, routing saja bukan jawaban yang lengkap. Tunnel antara kedua firewall memberi Anda kerahasiaan dan autentikasi peer, dan tabel rute di dalamnya adalah tabel yang sama yang akan Anda tulis di transit.

Putuskan itu dari pertanyaan kepercayaan di bagian pertama, bukan dari kebiasaan bahwa VPN lebih aman. Tunnel di atas segmen yang sudah privat menambah biaya operasional dan satu lagi mode kegagalan tanpa manfaat, sedangkan routing di atas segmen yang tidak dipercaya menukar kerahasiaan dengan kesederhanaan yang tidak mampu Anda bayar. Catat syarat mana dari ketiganya yang mendorong pilihan itu, dan insinyur berikutnya tidak perlu memperdebatkannya lagi.