Dua alamat layanan pada satu klien OpenVPN: iroute dan lo

Aplikasi menjawab pada alamat tunnel-nya, sedangkan alamat yang Anda dokumentasikan untuknya tidak menuju ke mana-mana. Tidak ada keluhan di log OpenVPN, peer tampak terhubung, dan hub mencantumkan tepat satu klien. Celahnya adalah alamat kedua pada klien merupakan dua fakta terpisah: host harus memilikinya, dan hub harus tahu peer mana yang memilikinya. Tangani satu tanpa yang lain dan lalu lintasnya mati di hub atau tiba tanpa rute pulang.

Alias bersifat lokal, kepemilikannya bersifat jarak jauh

Alamat tunnel dinegosiasikan, sehingga kedua ujung mempelajarinya saat handshake. Alamat layanan tambahan sama sekali tidak dinegosiasikan, itu sebabnya menambahkannya tidak mengubah apa pun di hub dengan sendirinya. Klien bisa langsung memiliki alamat itu dan server tetap akan mengirim lalu lintas tersebut ke jalur bawaannya atau menjatuhkannya. Dua catatan harus dibuat, di dua tempat berbeda.

Pada klien, alamat itu milik host, dan loopback adalah rumah alami bagi identitas layanan yang tidak boleh pernah muncul di tautan fisik. Di hub, pemetaan peer-ke-prefix adalah deklarasi terpisah yang hanya dibaca server. Tidak ada catatan yang menyiratkan yang lain.

Jaga kedua rentang tetap terpisah juga di catatan Anda. Alamat dalam contoh adalah nilai dokumentasi, dan menumpanginya dengan LAN sungguhan adalah cara tercepat membuat penyiapan yang berfungsi tampak rusak.

Tambahkan alamat pada klien secara persisten

Letakkan alamat layanan pada loopback dengan prefiks host, agar host memperlakukannya sebagai masukan lokal dan bukan sebagai subnet yang harus dicapai. ip address add 10.66.0.10/32 dev lo melakukannya untuk satu alamat, dan mengulangi perintah untuk alamat kedua memodelkan dua layanan.

Jalankan itu sebagai uji sekali pakai, lalu pindahkan ke apa pun yang memiliki konfigurasi jaringan host, karena penambahan saat runtime hilang saat reboot dan duplikat menumpuk di antara sambungan ulang. Unit systemd yang diurutkan setelah jaringan adalah salah satu opsi, dan manajer jaringan distribusi adalah opsi lain. Apa pun yang Anda pilih, alamat harus ada sebelum aplikasi mengikat, atau layanan muncul pada soket yang salah. Verifikasi dengan ip address show dev lo setelah reboot, bukan setelah perintah manual.

Pengikatan adalah keputusan terpisah dari pengalamatan. Aplikasi yang mendengarkan di setiap alamat menerima lalu lintas pada antarmuka yang tidak pernah Anda maksudkan, jadi arahkan ke alamat layanan tertentu. Dengan begitu kebijakan masukan lokal punya sesuatu yang tepat untuk dicocokkan.

Klaim di berkas CCD yang benar-benar dibaca hub

Di server, deklarasi kepemilikan masuk ke berkas per klien yang dipilih oleh nama umum yang terautentikasi, di dalam direktori yang dinamai oleh client-config-dir. Barisnya iroute 10.66.0.10 255.255.255.255, satu per alamat, dan memberi tahu server peer mana yang harus menerima lalu lintas untuk tujuan itu.

Dua detail mematahkan ini secara diam-diam. Nama berkas harus cocok dengan nama yang benar-benar dipakai server, yang berbeda ketika username-as-common-name dimainkan. Dan iroute hanya berlaku dalam mode TUN dengan direktori konfigurasi klien dikonfigurasi, jadi baris yang sama tidak melakukan apa pun dalam penyebaran berjembatan. Tambahkan baris ke berkas yang ada alih-alih menggantinya, karena berkas itu mungkin sudah membawa alamat tetap atau opsi push. Referensi OpenVPN 2.6 mendokumentasikan direktori dan direktif kepemilikan.

Kernel hub sendiri juga membutuhkan jalur ke tujuan tersebut agar lalu lintas yang dihasilkan secara lokal masuk ke proses tunnel. route 10.66.0.10 255.255.255.255 dalam konfigurasi server mencakup lalu lintas yang berasal dari server, sedangkan klien lain membutuhkan push "route 10.66.0.10 255.255.255.255" untuk mempelajari tujuan itu sendiri.

Perutetan dan otorisasi tetap terpisah. Rute yang didorong memberi tahu klien ke mana mengirim paket dan tidak memberikan apa pun; layanan tetap harus menerima pemanggil dengan ketentuannya sendiri.

Periksa kebijakan masukan dan jalur balasan

Paket yang dialamatkan ke alias tiba di host pemilik sebagai masukan lokal, jadi pertanyaannya apakah firewall lokal mengizinkan sumber dan port itu. Izinkan port layanan tertentu dari rentang sumber VPN alih-alih membuka seluruh alamat.

Balasan membutuhkan jalur kembali ke pemanggil. Bagi pemanggil di dalam kumpulan tunnel normal jalur itu sudah ada, karena perangkat tunnel membawanya. Pemanggil di belakang jaringan terutekan lain juga membutuhkan rute balik jaringan itu, dan di sinilah penyiapan asimetris kehilangan paket.

Waspadai pendengar kedua pada port yang sama yang terikat ke alamat berbeda, karena kernel mengirim ke soket mana pun yang cocok dan hasilnya tampak acak. Periksa dengan ss -lntp dan pastikan alamat yang terikat adalah alias layanan. NAT sumber tidak diperlukan di sini, dan menambahkannya menyembunyikan identitas pemanggil yang menjadi andalan log Anda.

Uji alamat dan kepemilikan secara terpisah

Uji dalam dua langkah. Pertama pastikan host pemilik dapat mencapai layanan pada alias-nya dari dirinya sendiri, yang memisahkan masalah pengikatan dan firewall dari perutetan. Lalu uji dari pemanggil VPN sungguhan menggunakan autentikasi aplikasi itu sendiri. Ketika yang pertama lolos dan yang kedua gagal, bagian yang hilang ada di sisi hub.

Periksa juga mode kegagalan yang bertahan setelah koneksi: alias tetap ditetapkan ketika tunnel mati, dan hub menyimpan rutenya ketika peer tidak ada. Tidak ada objek yang sendirian membuktikan layanan dapat dijangkau, itulah sebabnya uji dua langkah mengalahkan satu ping dari laptop.