Relay berfungsi dalam tiga peringkat, dan hanya peringkat tengah melintasi VPN. Klien menyiarkan pada segmen cawangan, ASA menukar siaran itu kepada permintaan unicast kepada pelayan DHCP, dan pelayan menjawab alamat relay dan bukan klien. Lalui peringkat itu mengikut urutan tersebut, dan kebanyakan kes «relay rosak» berakhir dengan dasar yang hilang atau baris setroute yang salah dibaca.

Peringkat satu: aktifkan relay pada antara muka yang menghadap klien

Pada ASA cawangan, relay ialah sifat antara muka yang menghadap klien. Pelayan boleh diisytiharkan secara global dengan antara muka yang boleh dicapai, atau di bawah antara muka menghadap klien itu supaya jadual penghalaan memilih laluan keluar. Kedua-dua bentuk itu tidak boleh ditukar ganti, dan menyalin yang salah ialah tempat pertama panduan tersasar.

Periksa konfigurasi yang berjalan sebelum mengubah apa-apa: antara muka mana yang mengaktifkan relay, bentuk pelayan mana yang ada, dan sama ada setroute dipasang pada antara muka klien. Jika ASA juga menjalankan pelayan DHCP untuk segmen lain, berhenti dan baca senarai sekatan; pelayan dan relay tidak boleh diaktifkan serentak pada peranti yang sama.

Relay meletakkan alamatnya sendiri yang menghadap klien dalam medan alamat get laluan. Alamat itulah yang akan dijawab oleh pelayan, jadi ia mesti boleh dicapai dari tapak jauh melalui terowong, bukan hanya secara setempat.

Peringkat dua: bawa trafik yang dijana ASA melalui terowong

Inilah langkah yang orang langkau. VPN tapak-ke-tapak berasaskan dasar biasanya dibina untuk trafik antara subnet, dan permintaan relay dijana oleh ASA sendiri. Jika senarai akses terowong dan peta kripto hanya sepadan dengan aliran dari hos cawangan ke subnet pelayan, paket relay mungkin tidak pernah masuk ke terowong. Periksa senarai akses dalam kedua-dua arah, bukan hanya baris cawangan-ke-pelayan.

Sahkan trafik menarik meliputi sumber relay ASA dan alamat pelayan, dan arah balik juga dibenarkan. Dalam reka bentuk berasaskan VTI keputusan penghalaan lebih mudah, tetapi sokongan relay melalui VTI datang dalam keluaran tertentu; panduan DHCP ASA menyebut 9.14(1), jadi periksa imej sebelum menyalin contoh VTI ke peranti yang lebih lama.

Ping dari ASA ke pelayan tidak banyak membuktikan dengan sendirinya. Ia boleh berjaya melalui laluan lain, dengan alamat sumber lain, atau di bawah dasar yang paket relay tidak sepadan.

Peringkat tiga: baca balasan dan pilihan setroute

RFC 2131 menyatakan pelayan menghantar balasannya ke alamat dalam giaddr apabila medan itu bukan sifar. Jadi laluan balik mesti dihalakan ke alamat relay, dan dasar terowong mesti membenarkan arah pelayan-ke-relay. Jika permintaan melepasi tetapi tawaran tidak pernah tiba, di sinilah tempat untuk melihat.

Kemudian pisahkan dua perkara yang kedengaran serupa. Kata kunci setroute mengubah atau menambah pilihan penghala lalai yang diberikan ASA kepada klien. Ia tidak memasang laluan pada ASA dan tidak mencipta dasar VPN. Klien yang mendapat alamat tetapi tidak dapat mencapai apa-apa selalunya mengalami masalah setroute atau skop, bukan masalah terowong. Ujinya dengan klien tanpa get laluan statik dan perhatikan penghala lalai mana yang muncul dalam tawaran.

Baca tawaran dari awal hingga akhir: alamat yang ditawarkan, mask, penghala lalai, DNS dan masa pajakan. Kemudian biarkan pajakan diperbaharui. Relay yang berjaya sekali dan gagal semasa pembaharuan biasanya mempunyai masalah skop, pajakan atau laluan balik yang disembunyikan oleh pertukaran pertama.

Apa yang saya periksa sebelum mengatakan ia sudah dibaiki

Mulakan dari klien dan tangkap siaran, kemudian sahkan ASA memajukannya dengan alamatnya sendiri sebagai giaddr. Di sisi jauh, sahkan pelayan melihat permintaan itu dan memilih skop yang sepadan dengan cawangan. Kembali di cawangan, sahkan klien menerima tawaran dan dapat mencapai get laluannya.

Jika mana-mana peringkat senyap, periksa dasar atau laluan yang sepadan dan bukannya menambah kenyataan relay lain. Konfigurasi relay biasanya sudah betul pada masa seseorang meningkatkannya; dasar terowong atau laluan balik yang berubah.

Tulis ketiga-tiga peringkat dalam rekod perubahan: antara muka menghadap klien, dasar VPN yang meliputi trafik relay, dan laluan balik pelayan ke giaddr. Rekod itulah yang menjadikan pembinaan cawangan seterusnya kerja yang boleh diulang dan bukan sesi nyahpepijat. Ia juga memberitahu jurutera seterusnya output arahan mana yang perlu dikumpul dahulu.

Artikel berkaitan