Siapa yang sebenarnya menjawab di alamat khusus VPN itu?

Alamat yang tergeletak tidak terpakai dalam alokasi organisasi bukanlah pendengar, dan menambahkannya ke firewall tidak menciptakan satu pun. Sesuatu harus mengakhiri IKE di alamat itu, dan mekanismenya berbeda tergantung apakah gateway memiliki alamat itu atau perangkat hulu menerjemahkannya. Jalur paketlah yang membedakan keduanya, dan itu menentukan fitur platform mana yang Anda butuhkan sebelum siapa pun membuka permintaan perubahan. Modelkan jalurnya dulu, lalu pilih.

Jalur paket di balik alamat

Peer mengirim IKE ke alamat yang diberikan kepadanya, pada UDP 500 atau pada UDP 4500 saat penelusuran NAT berperan. Perangkat mana pun yang memegang alamat itu di jalur tersebut entah menerima datagram secara lokal dan menjawabnya, atau meneruskannya ke tempat lain. Hanya itu dua kemungkinan, dan semua hal lain di artikel ini mengalir dari mana yang benar.

Menerima secara lokal berarti ada soket di perangkat itu, terikat pada alamat tersebut. Meneruskan berarti datagram ditulis ulang dan dikirim ke titik ujung lain, yang kemudian memegang soket. Aturan firewall yang mengizinkan UDP 500 tidak memberi tahu Anda apa pun tentang mana dari keduanya yang terjadi.

Tulis catatannya sebelum Anda menyentuh apa pun: alamat yang dihubungi peer, bagaimana jaringan hulu mengantarkannya, antarmuka lokal atau titik ujung logis yang menerimanya, dan proses yang menjawab IKE. Empat baris, dan setiap baris dapat diperiksa. Ketika salah satunya tidak diketahui, ketidaktahuan itu adalah pekerjaan desain, bukan detail implementasi yang akan diselesaikan nanti. Mengisinya setelah permintaan perubahan disetujui adalah cara aturan penerjemahan ditambahkan ke perangkat yang salah.

Model A: gateway memiliki alamat itu

Pada model pertama gateway memegang alamatnya sendiri, baik sebagai alamat sekunder pada antarmuka yang ada, sebagai alamat pada antarmuka khusus, atau sebagai loopback yang didukung platform sebagai titik ujung terowongan. Itu tiga fitur berbeda dengan tiga jalur konfigurasi berbeda, dan platform yang mendukung satu mungkin tidak mendukung yang lain.

Pastikan platform dan rilis mendukung susunan persis itu sebelum Anda merancang di sekitarnya. Blok terrutekan, alamat tambahan pada antarmuka, dan titik ujung loopback tidak dapat dipertukarkan, dan dokumentasi satu rilis tidak menjanjikan rilis berikutnya bersikap sama.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

Soket yang mendengarkan adalah buktinya. Jika tidak ada yang terikat pada alamat itu, gateway bukan pengakhir apa pun kata tabel perutean, dan penangkapan paket akan menunjukkan datagram datang tanpa ada yang menjawabnya.

Jangan menempatkan antarmuka kedua ke dalam subnet yang sudah ada di tempat lain dalam topologi dan menganggap platform akan mengurusnya. Subnet antarmuka yang tumpang tindih menghasilkan pemilihan sumber yang ambigu dan, pada banyak platform, penolakan untuk dikonfigurasi sama sekali.

Model B: perangkat hulu menerjemahkannya

Pada model kedua firewall hulu memegang alamat khusus itu dan meneruskan lalu lintas ke gateway VPN yang berbeda. Itu penerjemahan tujuan dengan jalur kembali, dan itu desain yang sepenuhnya sah selama didokumentasikan sebagai demikian.

Yang bukan, adalah bukti bahwa perangkat hulu memperoleh soket VPN lokal. Penerjemahan meneruskan paket; itu tidak menjadikan kotak atas sebagai penjawab IKE. Jika aturan hulu dihapus atau jalur kembalinya rusak, VPN berhenti meskipun gateway sehat dan pendengarnya sendiri utuh.

Catat kedua alamat: yang dihubungi peer dan yang benar-benar dilihat gateway. Lalu catat transpor dan jalur kembali, karena penerjemahan yang bekerja untuk UDP 500 tetapi tidak untuk ESP terenkapsulasi akan terhubung lalu gagal membawa lalu lintas, yang merupakan kegagalan membingungkan untuk di-debug nanti.

Identitas bukan alamat luar

IPsec memisahkan titik ujung terowongan dari lalu lintas yang dilindunginya, dan arsitektur menyimpan keputusan itu di tempat berbeda. Mengubah alamat yang dihubungi peer tidak otomatis mengubah prefiks dalam mana yang diizinkan, rute mana yang dipasang, atau sumber daya mana yang dapat dijangkau sesi.

Identitas yang terautentikasi terpisah lagi. IKEv2 membawa muatan identitas dan pertukaran autentikasi yang tidak harus cocok dengan alamat paket luar, dan justru itulah sebabnya desain yang diterjemahkan masih dapat mengautentikasi dengan benar.

Kemandirian itu berguna dan juga jebakan. Dua nama DNS yang mengarah ke satu pendengar biasa tidak memilih backend VPN yang berbeda, dan sertifikat yang menyebut satu identitas tidak akan memuaskan peer yang mengharapkan identitas lain. Pastikan apa yang divalidasi peer sebelum Anda menganggap alamat saja yang menentukannya.

Terima desainnya dengan mengamati satu koneksi

Periksa ke mana koneksi baru yang diizinkan benar-benar dikirim, identitas mana yang menjawab, dan aliran privat mana yang kemudian diizinkan. Tiga pengamatan, tiga lapisan berbeda, dan pencarian publik alamat yang berhasil tidak menguji satu pun darinya.

Pertahankan juga kasus negatifnya: peer yang seharusnya tidak diterima, atau prefiks dalam yang seharusnya tidak terjangkau, diverifikasi setelah perubahan. Catatan yang Anda tulis di awal itulah yang membuat pengujian itu mungkin tanpa merekonstruksi desain dari ingatan.

Inti dari semua ini adalah membiarkan pemilik jaringan memilih metode alokasi yang didukung alih-alih bersandar pada klaim umum tentang apa yang dapat dilakukan setiap firewall dengan alamat tambahan. Klaim itulah justru titik di mana desain ini salah, karena terdengar masuk akal di setiap platform dan secara umum tidak benar di satu pun. Catatan empat baris menentukannya untuk platform Anda dalam sepuluh menit.