Relay DHCP ASA melalui VPN site-to-site: panduan langkah demi langkah

Relay bekerja dalam tiga tahap, dan hanya tahap tengah yang melintasi VPN. Klien menyiarkan di segmen cabang, ASA mengubah siaran itu menjadi permintaan unicast ke server DHCP, dan server menjawab alamat relay, bukan klien. Lalui tahap-tahapnya dalam urutan itu, dan sebagian besar kasus «relay rusak» bermuara pada kebijakan yang hilang atau baris setroute yang salah dibaca.

Tahap satu: aktifkan relay pada antarmuka yang menghadap klien

Pada ASA cabang, relay adalah properti antarmuka yang menghadap klien. Server dapat dideklarasikan secara global dengan antarmuka yang dapat dijangkau, atau di bawah antarmuka yang menghadap klien itu agar tabel routing memilih jalan keluar. Kedua bentuk itu tidak dapat dipertukarkan, dan menyalin yang salah adalah tempat pertama sebuah panduan melenceng.

Periksa konfigurasi yang berjalan sebelum mengubah apa pun: antarmuka mana yang mengaktifkan relay, bentuk server mana yang ada, dan apakah setroute terpasang pada antarmuka klien. Jika ASA juga menjalankan server DHCP untuk segmen lain, berhentilah dan baca daftar batasan; server dan relay tidak dapat diaktifkan bersamaan pada perangkat yang sama.

Relay menempatkan alamatnya sendiri yang menghadap klien ke dalam bidang alamat gateway. Alamat itulah yang akan dijawab server, jadi alamat itu harus dapat dijangkau dari situs jauh melalui tunnel, bukan hanya secara lokal.

Tahap dua: bawa lalu lintas yang dihasilkan ASA melewati tunnel

Inilah langkah yang dilewati orang. VPN site-to-site berbasis kebijakan biasanya dibangun untuk lalu lintas antar-subnet, dan permintaan relay dihasilkan oleh ASA sendiri. Jika daftar akses tunnel dan peta kripto hanya cocok dengan aliran dari host cabang ke subnet server, paket relay mungkin tidak pernah masuk ke tunnel. Periksa daftar akses di kedua arah, bukan hanya baris cabang-ke-server.

Pastikan lalu lintas yang menarik mencakup sumber relay ASA dan alamat server, serta arah balik juga diizinkan. Pada desain berbasis VTI keputusan routing lebih sederhana, tetapi dukungan relay melalui VTI hadir pada rilis tertentu; panduan DHCP ASA menyebutkan 9.14(1), jadi periksa image sebelum menyalin contoh VTI ke perangkat yang lebih lama.

Ping dari ASA ke server tidak banyak membuktikan apa pun. Ping bisa berhasil melalui jalur lain, dengan alamat sumber lain, atau di bawah kebijakan yang tidak cocok dengan paket relay.

Tahap tiga: baca balasan dan opsi setroute

RFC 2131 menyatakan bahwa server mengirim balasannya ke alamat pada giaddr ketika bidang itu bukan nol. Jadi jalur balik harus dirutekan ke alamat relay, dan kebijakan tunnel harus mengizinkan arah server-ke-relay. Jika permintaan lolos tetapi tawaran tidak pernah tiba, di sinilah tempat mencarinya.

Lalu pisahkan dua hal yang terdengar mirip. Kata kunci setroute mengubah atau menambahkan opsi router default yang diberikan ASA kepada klien. Kata kunci itu tidak memasang rute pada ASA dan tidak membuat kebijakan VPN. Klien yang mendapat alamat tetapi tidak dapat mencapai apa pun sering mengalami masalah setroute atau cakupan, bukan masalah tunnel. Ujilah dengan klien tanpa gateway statis dan amati router default mana yang muncul dalam tawaran.

Baca tawaran dari awal sampai akhir: alamat yang ditawarkan, mask, router default, DNS, dan masa sewa. Lalu biarkan sewa diperbarui. Relay yang berhasil sekali dan gagal saat pembaruan biasanya memiliki masalah cakupan, sewa, atau jalur balik yang disembunyikan oleh pertukaran pertama.

Apa yang saya periksa sebelum menyebutnya beres

Mulai dari klien dan tangkap siarannya, lalu pastikan ASA meneruskannya dengan alamatnya sendiri sebagai giaddr. Di sisi jauh, pastikan server melihat permintaan itu dan memilih cakupan yang sesuai dengan cabang. Kembali di cabang, pastikan klien menerima tawaran dan dapat mencapai gateway-nya.

Jika ada tahap yang diam, periksa kebijakan atau rute yang sesuai alih-alih menambahkan pernyataan relay lain. Konfigurasi relay biasanya sudah benar pada saat seseorang mengeskalasi; kebijakan tunnel atau rute baliklah yang berubah.

Tulis ketiga tahap ke dalam catatan perubahan: antarmuka yang menghadap klien, kebijakan VPN yang mencakup lalu lintas relay, dan rute balik server ke giaddr. Catatan itulah yang membuat pembangunan cabang berikutnya menjadi pekerjaan yang dapat diulang, bukan sesi debugging. Catatan itu juga memberi tahu insinyur berikutnya keluaran perintah mana yang harus dikumpulkan lebih dulu.