Gateway dapat memberikan alamat virtual IPv4 dan IPv6 sekaligus kepada pengguna nomaden, sementara tunnel luar tetap melintas di atas IPv4. Itu keputusan yang saling independen, dan memperlakukannya sebagai satu justru menjadi titik rencana dual-stack biasanya berantakan. Famili internal klien, prefiks yang dilindungi yang dapat dijangkau, dan transport yang membawa enkapsulasi adalah tiga pilihan terpisah.

Sebagian besar kebingungan muncul karena kata dual stack diterapkan pada rancangan yang dual stack hanya di satu tempat. Layanan bisa dual stack di dalam, single stack pada alamat luarnya, dan tetap bekerja dengan sangat baik bagi klien. Yang tidak bisa dilakukannya adalah bekerja secara kebetulan.

Dua famili di dalam, satu jalur di luar

Koneksi luar adalah IKE di atas UDP, dan membutuhkan satu famili alamat yang dapat dijangkau dari mana pun klien berada. Alamat IPv6 internal tidak memerlukan penyedia yang mendukung IPv6, karena paket internal adalah muatan di dalam paket luar. Banyak penerapan yang berjalan mengangkut prefiks IPv6 melalui uplink yang hanya IPv4.

Yang benar-benar dibatasi jalur luar adalah keterjangkauan dan lintasan NAT. Jika gateway hanya mengumumkan alamat IPv4, klien pada jaringan yang hanya IPv6 sama sekali tidak dapat terhubung, berapa pun kumpulan alamat yang Anda konfigurasikan. Tentukan famili luar berdasarkan populasi klien Anda, bukan berdasarkan rencana alamat internal.

Beri klien alamat di setiap famili

Meminta kedua famili adalah satu baris pernyataan di sisi klien, asalkan gateway punya sesuatu untuk dibagikan. Kumpulan alamat bernama menjaga sumber tetap terpisah dari jaringan layanan, dan itulah sifat yang membuat aturan firewall tetap terbaca enam bulan kemudian.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Nilai vips meminta satu alamat dari setiap famili, dan daftar kumpulan alamat menentukan dari mana alamat itu berasal. Dokumentasi strongSwan tentang IP virtual mencakup banyak permintaan dan penetapan kumpulan alamat, termasuk poin bahwa klien yang meminta alamat tertentu hanya menyatakan preferensi yang boleh diabaikan oleh penjawab. Jangan membangun aturan akses yang mengasumsikan klien selalu menerima nilai yang sama.

Buat prefiks lokal unik Anda sendiri alih-alih menyalin contoh. Dua organisasi yang keduanya fd42::/16 menerapkannya akan menemukan bentrokan saat pertama kali saling terhubung, dan mendiagnosisnya tidak menyenangkan.

Selektor menggambarkan tujuan, bukan sumber

Selektor lalu lintas lokal SA anak menyatakan jaringan terlindungi mana yang berada di belakang gateway, dan selektor jarak jauh menggambarkan apa yang boleh dipakai klien sebagai sumber. Alamat kumpulan alamat virtual berada di sisi sumber kebijakan itu; menempatkannya dalam daftar tujuan adalah salah baca konfigurasi yang lazim.

Kedua famili memerlukan rute balik dan penerusan yang diizinkan di gateway. Menambahkan prefiks ke selektor tanpa rute kembali ke kumpulan alamat menghasilkan tunnel yang terbentuk, melewatkan satu arah lalu lintas, lalu menjatuhkan balasannya secara diam-diam. Selektor adalah kebijakan, bukan perutean.

Jaga kumpulan alamat dan prefiks layanan dalam blok terpisah pada rencana alamat Anda. Saat keduanya tumpang tindih, rute yang seharusnya mencapai host terlindungi bisa cocok dengan alamat kumpulan dan hilang ke dalam tunnel.

DNS dan jalur balasan menentukan apakah ini terasa selesai

Jawaban resolver tidak bergantung pada transport yang dipakai untuk mencapainya. Sebuah nama dapat mengembalikan record A, record AAAA, atau keduanya, dan klien memilih menurut aturan preferensinya sendiri. Jika layanan internal menerbitkan record AAAA tetapi tidak ada yang merutekan prefiks itu, klien di jaringan dual-stack akan mencoba jalur IPv6 lebih dulu dan bertahan di sana sampai gagal. Tidak ada yang tampak salah pada konfigurasi tunnel selama itu terjadi.

Jadi tentukan per nama famili mana yang harus dapat digunakan, lalu periksa bahwa prefiks yang sesuai ada di selektor dan memiliki rute balik. Itu keputusan per layanan. Menerbitkan kedua jenis record secara menyeluruh adalah cara layanan yang berjalan hanya dengan IPv4 mulai kehabisan waktu bagi separuh penggunanya.

Verifikasi kedua famili sebelum menyatakannya selesai

Konfigurasi yang termuat bukan konfigurasi yang bekerja. Baca status yang dilaporkan daemon, konfirmasi penetapan kumpulan alamat, lalu lihat rute yang benar-benar dipasang klien.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Dua perintah pertama menunjukkan SA anak yang terbentuk dan kumpulan alamat mana yang masih punya alamat tersedia, sehingga rencana yang berhasil untuk klien pertama dan gagal pada klien kesepuluh menjadi terlihat. Dua perintah terakhir menunjukkan apakah klien menerima alamat IPv6 global dari kumpulan alamat dan ke mana lalu lintas ke prefiks terlindungi sebenarnya akan pergi. Bandingkan alamat yang diberikan dengan kumpulan alamat yang Anda konfigurasikan, bukan dengan alamat yang Anda harapkan. Jika penjawab memilih nilai berbeda menurut kebijakannya, rute dan aturan firewall tetap harus selaras dengan pilihannya.

Lalu uji satu host terlindungi per famili, dan uji nama yang terurai ke keduanya. Uji satu famili tidak memberi tahu apa pun tentang separuh rencana yang belum Anda latih, dan di situlah biasanya rute yang hilang berada.

Artikel terkait