Bolehkah Klien VPN Berayau Menghos Layanan untuk Pejabat?

Komputer riba pejabat anda boleh mendail masuk dari rumah dan masih menyediakan sesuatu yang pejabat perlukan, tetapi hanya apabila tiga keputusan berasingan sejajar. Terowong ialah pengangkutan, alamat dalaman ialah destinasi, dan dasar menentukan siapa boleh mengetuk. Menganggap mana-mana satu daripadanya sebagai jawapan penuh menghasilkan aduan biasa: hos menjawab ping tetapi aplikasi tidak pernah bersambung. Peranannya tidak sama, dan perbezaannya terletak tepat di tempat kerja reka bentuk berada.

Arah dail masuk tidak berkata apa-apa tentang arah layanan

Apabila klien memulakan terowong, ia membuka laluan yang boleh digunakan oleh kedua-dua arah sebaik sahaja ia wujud. Sama ada sambungan baharu boleh masuk dari hab ke arah klien itu ialah soal dasar gateway, bukan sifat orang yang mendail. Pada hab OpenVPN yang dihalakan, sebagai contoh, pelayan memerlukan laluan ke alamat dalaman klien dan penghantaran semula yang membenarkan hubungan rakan setara.

Bayangkan sistem inventori yang meninjau agen pada komputer riba berayau, atau pembangun yang memerlukan API ujian dari stesen kerja di rumah. Kedua-duanya mahu pihak pejabat memulakan perbualan, iaitu bertentangan dengan corak klien-ke-pelayan biasa.

Produk akses jauh yang dihoskan berbeza di sini, dan perbezaan itu bukan pepijat. Sesetengah VPN perkhidmatan terurus menyekat sambungan tidak diminta ke arah klien yang bersambung secara sengaja kerana model mereka ialah klien-ke-sumber, bukan sumber-ke-klien. Baca seni bina produk yang didokumenkan sebelum berjanji kepada rakan sekerja bahawa komputer ribanya boleh bertindak sebagai pelayan.

Ikut laluan balasan sebelum membuka port

Laluan itu mempunyai tiga bahagian: laluan pada gateway yang menunjuk ke alamat dalaman klien, dasar yang membenarkan pemanggil tertentu, dan perkhidmatan yang mendengar pada sasaran. Setiap bahagian gagal secara berbeza, sebab itulah «VPN menyala» hampir tidak memberitahu apa-apa.

Berita baiknya ialah laluan dalaman tidak memerlukan penghantaran port pada penghala rumah klien. Itulah maksud menerbitkan perkhidmatan pada alamat terowong dan bukan pada alamat WAN rumah, di mana pendedahan dan peraturan NAT akan sama sekali berbeza. Penghala rumah juga mungkin enggan melakukan hairpin pada sambungan yang datang dari pejabat, jadi laluan WAN gagal atas sebab yang tidak berkaitan dengan VPN anda. Menyimpan trafik di dalam terowong mengelakkan kedua-dua masalah sekali gus.

Periksa juga bahagian sasaran. Perkhidmatan yang terikat hanya pada 127.0.0.1 tidak boleh menerima sambungan yang tiba pada antara muka terowong, walau seberapa betul laluan gateway. Peraturan tembok api hos yang membenarkan port hanya dari subrangkaian tempatan juga akan menggugurkan trafik pejabat, dan peraturan itu bebas daripada dasar VPN di atasnya.

Nama dan alamat ialah keputusan reka bentuk

Alamat di dalam terowong bukan secara automatik nama. Rekod DNS peribadi yang anda kawal lebih jelas daripada berharap protokol penemuan melintasi terowong, kerana penyelesaian nama multicast pautan-tempatan kekal pada segmen tempatan dan tidak menjadi DNS antara subrangkaian.

Kestabilan alamat sama pentingnya. Jika klien VPN mengambil dari kumpulan dengan pajakan pendek, alamat dalaman komputer riba berubah antara sesi dan setiap penanda buku, skop tembok api dan pemeriksaan pemantauan yang dibina di atasnya rosak secara senyap. Gunakan tempahan atau laluan kemas kini dinamik yang didokumenkan.

Setujui nama itu dengan pemilik identiti VPN, supaya rekod, peruntukan alamat dan dasar akses berubah bersama dan bukan dalam tiga tiket berasingan.

Uji layanan itu, bukan keahlian

Dari sasaran, sahkan apa yang mendengar dan pada alamat mana, kemudian sahkan pandangan gateway tentang laluan balik:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Sekarang uji dari pihak pejabat dengan permintaan sebenar dan bukan gema. curl yang berjaya terhadap perkhidmatan membuktikan laluan, dasar dan pendengar sekali gus, manakala ping yang berjaya hanya membuktikan ICMP dibenarkan. Jika permintaan gagal, telusuri ke belakang melalui ketiga-tiga bahagian dan bukan melebarkan tembok api sambil berharap.

Ketersediaan tergolong dalam perbualan yang sama. Komputer riba tidur, berayau antara rangkaian dan terputus pada penghujung hari. Perkhidmatan yang mesti menjawab pada bila-bila masa tergolong pada hos yang sentiasa hidup, manakala perkhidmatan usaha terbaik boleh kekal pada klien dengan had itu dicatatkan.

Terbitkan sumber itu secara sengaja, dengan nama, senarai pemanggil yang dibenarkan dan pemilik, dan peranti jauh menjadi perkhidmatan yang disokong dan bukan pelayan tidak sengaja.