Dua alamat perkhidmatan pada satu klien OpenVPN: iroute dan lo

Aplikasi menjawab pada alamat terowongnya, dan alamat yang anda dokumentasikan untuknya tidak menuju ke mana-mana. Tiada apa-apa dalam log OpenVPN yang mengeluh, rakan setara kelihatan bersambung, dan hab menyenaraikan tepat satu klien. Jurangnya ialah alamat kedua pada klien ialah dua fakta berasingan: hos mesti memilikinya, dan hab mesti tahu rakan setara mana yang memilikinya. Kendalikan satu tanpa yang lain dan trafik sama ada mati di hab atau tiba tanpa laluan pulang.

Alias bersifat setempat, pemilikan bersifat jauh

Alamat terowong dirundingkan, jadi kedua-dua hujung mempelajarinya semasa jabat tangan. Alamat perkhidmatan tambahan tidak dirundingkan sama sekali, itulah sebabnya menambahnya tidak mengubah apa-apa di hab dengan sendirinya. Klien boleh memiliki alamat itu serta-merta dan pelayan masih akan menghantar trafik itu ke laluan lalainya atau menggugurkannya. Dua rekod mesti dicipta, di dua tempat berbeza.

Pada klien, alamat itu milik hos, dan loopback ialah rumah semula jadi bagi identiti perkhidmatan yang tidak sepatutnya muncul pada pautan fizikal. Di hab, pemetaan rakan setara ke awalan ialah pengisytiharan berasingan yang hanya dibaca pelayan. Tiada rekod yang mengandaikan yang lain.

Kekalkan kedua-dua julat berasingan dalam nota anda juga. Alamat dalam contoh ialah nilai dokumentasi, dan bertindih dengannya dengan LAN sebenar ialah cara terpantas membuat persediaan yang berfungsi kelihatan rosak.

Tambahkan alamat pada klien secara berterusan

Letakkan alamat perkhidmatan pada loopback dengan awalan hos, supaya hos menganggapnya sebagai input setempat dan bukan sebagai subrangkaian yang perlu dicapai. ip address add 10.66.0.10/32 dev lo melakukannya untuk satu alamat, dan mengulang arahan untuk alamat kedua memodelkan dua perkhidmatan.

Jalankan itu sebagai ujian sekali sahaja, kemudian pindahkannya ke apa yang memiliki konfigurasi rangkaian hos, kerana penambahan semasa jalan hilang apabila but semula dan pendua terkumpul antara sambungan semula. Unit systemd yang disusun selepas rangkaian ialah satu pilihan, dan pengurus rangkaian edaran ialah satu lagi. Apa pun yang anda pilih, alamat mesti wujud sebelum aplikasi mengikat, jika tidak perkhidmatan muncul pada soket yang salah. Sahkan dengan ip address show dev lo selepas but semula dan bukan selepas arahan manual.

Pengikatan ialah keputusan berasingan daripada pengalamatan. Aplikasi yang mendengar pada setiap alamat menerima trafik pada antara muka yang tidak pernah anda maksudkan, jadi halakan ia ke alamat perkhidmatan tertentu. Kemudian dasar input setempat mempunyai sesuatu yang tepat untuk dipadankan.

Tuntut ia dalam fail CCD yang benar-benar dibaca hab

Pada pelayan, pengisytiharan pemilikan masuk ke fail setiap klien yang dipilih oleh nama biasa yang disahkan, di dalam direktori yang dinamakan oleh client-config-dir. Barisnya ialah iroute 10.66.0.10 255.255.255.255, satu bagi setiap alamat, dan ia memberitahu pelayan rakan setara mana yang patut menerima trafik untuk destinasi itu.

Dua butiran memecahkan ini secara senyap. Nama fail mesti sepadan dengan nama yang benar-benar digunakan pelayan, yang berbeza apabila username-as-common-name terlibat. Dan iroute hanya berkuat kuasa dalam mod TUN dengan direktori konfigurasi klien dikonfigurasikan, jadi baris yang sama tidak melakukan apa-apa dalam penggunaan berjambatan. Tambah baris pada fail sedia ada dan bukan menggantikannya, kerana ia mungkin sudah membawa alamat tetap atau pilihan push. Rujukan OpenVPN 2.6 mendokumentasikan direktori dan direktif pemilikan.

Kernel hab sendiri juga memerlukan laluan ke destinasi tersebut supaya trafik yang dijana secara setempat masuk ke proses terowong. route 10.66.0.10 255.255.255.255 dalam konfigurasi pelayan meliputi trafik yang dihasilkan pelayan sendiri, manakala klien lain memerlukan push "route 10.66.0.10 255.255.255.255" untuk mempelajari destinasi itu sendiri.

Penghalaan dan kebenaran kekal berasingan. Laluan yang ditolak memberitahu klien ke mana hendak menghantar paket dan tidak memberikan apa-apa; perkhidmatan masih perlu menerima pemanggil mengikut syaratnya sendiri.

Periksa dasar input dan laluan balasan

Paket yang dialamatkan kepada alias tiba di hos pemilik sebagai input setempat, jadi persoalannya ialah sama ada tembok api setempat membenarkan sumber dan port itu. Benarkan port perkhidmatan tertentu daripada julat sumber VPN dan bukan membuka seluruh alamat.

Balasan memerlukan laluan kembali kepada pemanggil. Bagi pemanggil dalam kumpulan terowong biasa laluan itu sudah wujud, kerana peranti terowong membawanya. Pemanggil di belakang rangkaian berpenghalaan lain juga memerlukan laluan pulang rangkaian itu, dan di sinilah persediaan tidak simetri kehilangan paket.

Perhatikan pendengar kedua pada port yang sama yang terikat pada alamat berbeza, kerana kernel menghantar kepada soket yang sepadan dan hasilnya kelihatan rawak. Periksa dengan ss -lntp dan sahkan bahawa alamat yang terikat ialah alias perkhidmatan. NAT sumber tidak diperlukan di sini, dan menambahnya menyembunyikan identiti pemanggil yang bergantung pada log anda.

Uji alamat dan pemilikan secara berasingan

Uji dalam dua langkah. Pertama sahkan hos pemilik boleh mencapai perkhidmatan pada aliasnya daripada dirinya sendiri, yang memisahkan masalah pengikatan dan tembok api daripada penghalaan. Kemudian uji daripada pemanggil VPN sebenar menggunakan pengesahan aplikasi itu sendiri. Apabila yang pertama lulus dan yang kedua gagal, bahagian yang hilang berada di sebelah hab.

Periksa juga mod kegagalan yang bertahan selepas sambungan: alias kekal ditetapkan apabila terowong turun, dan hab menyimpan laluannya apabila rakan setara tiada. Tiada objek bersendirian membuktikan perkhidmatan boleh dicapai, itulah sebabnya ujian dua langkah mengalahkan satu ping daripada komputer riba.