Pengguna gateway Access Server: merutekan LAN cabang klien
Di Access Server alamat tunnel klien bukan rute ke cabangnya. Deklarasikan pengguna gateway, lalu perbaiki kedua jalur balik dan penerusan.
Anda bisa ping alamat tunnel klien OpenVPN dan tetap tidak menjangkau satu pun host di LAN di belakangnya. Access Server memberi klien itu alamat dari kumpulan VPN, dan alamat kumpulan itulah satu-satunya yang dianggap dimiliki server. Prefiks cabang adalah fakta terpisah yang harus dideklarasikan, dan bahkan setelah itu cabang memerlukan penerus dan kantor pusat memerlukan jalur balik. Rute yang diketik di tempat salah tampak seperti perbaikan tetapi tidak mengubah apa pun.
Dua alamat, dua klaim kepemilikan berbeda
Saat klien terhubung, Access Server memberinya alamat dari kumpulan VPN yang dikonfigurasi, misalnya 10.90.0.0/24. Penetapan itu adalah sewa untuk satu host. Tidak ada dalam koneksi yang menyatakan bahwa klien yang sama juga berdiri di depan 10.60.0.0/24, dan server tidak akan menebak: prefiks LAN hanya dapat dijangkau melalui klien tertentu jika administrator mendeklarasikannya.
Karena itu rute statis di mesin lain tidak berhasil. Rute mengatakan kirim 10.60.0.0/24 ke alamat ini, tetapi jika alamat itu milik klien yang tidak pernah ditandai sebagai gateway, server tidak punya alasan mengantarkan paket tersebut ke sana, dan tumpukan klien bisa membuangnya. Deklarasi dan rute adalah dua bagian dari satu mekanisme.
Apa yang sebenarnya dipasang pengaturan gateway
Di Admin Web UI deklarasi itu adalah properti pengguna: aktifkan Configure VPN gateway pada pengguna konektor dan masukkan prefiks cabang yang sebenarnya di Network on the VPN client side. Pengguna tersebut diautentikasi seperti pengguna lain, jadi perlu kebijakan kredensial yang cocok untuk perangkat tanpa pengawasan, dan profil login otomatisnya adalah rahasia, bukan berkas kenyamanan.
Di balik kotak itu server memperlakukan prefiks sebagai dapat dijangkau melalui alamat kumpulan klien tersebut, dan konfigurasi perutean di bawah Access Controls menentukan apa yang diberitahukan kepada klien lain: rute yang didorong ke klien biasa dan aturan akses yang mengizinkan lalu lintas dari jaringan kantor pusat ke alamat dan subnet klien. Aktifkan perutean untuk jaringan yang harus mencapai cabang, dan jaga daftar izin tetap pendek.
Direktif bergaya Community yang ditempelkan ke berkas hasil generasi tidak ikut serta dalam model ini. Produk memiliki tabel perutean yang didorongnya; baris yang diedit tangan ditimpa pada generasi berikutnya atau diabaikan.
Lengkapi jalur balik kedua jaringan
Rencana konkret: kantor pusat 10.40.0.0/24, cabang 10.60.0.0/24, kumpulan VPN 10.90.0.0/24, dan Access Server dapat dijangkau pada alamat privat di sisi kantor pusat. Router kantor pusat memerlukan rute untuk prefiks cabang dan untuk kumpulan, keduanya menuju Access Server. Tanpa itu tunnel membawa permintaan dan balasannya keluar lewat gateway default, yang menghasilkan koneksi setengah terbuka yang klasik.
Di cabang, konektor harus meneruskan paket yang tidak dialamatkan kepadanya: penerusan IP di sistem operasinya ditambah izin penerusan yang dibatasi pada antarmuka tunnel dan LAN; di Linux itu net.ipv4.ip_forward=1 bersama aturan rantai forward, di Windows adalah routing and remote access. Setelah itu host di cabang memerlukan jalur balik: entah konektor menjadi gateway default mereka, atau gateway yang ada membawa rute khusus untuk prefiks kantor pusat dan kumpulan.
Tabel perutean konektor sendiri tidak mengonfigurasi ulang setiap host di LAN cabang. Jika host menunjuk ke router lain, rute balik berada di sana, dan router itu harus menerima bahwa alamat sumber yang dilihatnya bukan tetangga di subnet lokal.
Baca kegagalan sebagai jalur, bukan izin
Uji dalam urutan tetap. Pertama layanan yang diizinkan dari Access Server ke host di cabang, lalu layanan yang sama dari host biasa di kantor pusat, lalu arah sebaliknya jika kebijakan mengizinkan. Jika yang pertama lolos dan yang kedua gagal, rute yang didorong atau aturan akses adalah masalahnya. Jika keduanya lolos tetapi tidak ada balasan, periksa penerusan di cabang dan rute balik di kantor pusat.
Firewall host adalah tersangka berikutnya, karena dengan akses terutek tujuan melihat alamat kantor pusat atau kumpulan sebagai sumber. Aturan yang ditulis untuk subnet lokal tidak akan cocok dan paket dibuang setelah perutean bekerja sempurna.
Dua desain memerlukan lebih dari pola ini. Prefiks yang tumpang tindih antar lokasi membuat tujuan ambigu dan menuntut penomoran ulang atau penerjemahan, dan Access Server terklaster memerlukan setiap node memiliki jalur yang berfungsi ke konektor cabang, bukan satu node yang menyimpan rute. Terapkan perubahan lewat jalur simpan dan perbarui yang biasa, sambungkan ulang konektor, dan verifikasi lagi dari kedua ujung; boot ulang penuh setiap mesin bukan bagian dari prosedur.
Tutorial site-to-site Access Server mencantumkan pengaturan yang sama dalam urutan produk; ada baiknya mengikutinya sekali sebelum menyesuaikan desain dengan prefiks Anda sendiri.