Bisakah Klien VPN yang Berpindah Menghosting Layanan untuk Kantor?

Laptop kantor Anda dapat dial in dari rumah dan tetap menyediakan sesuatu yang dibutuhkan kantor, tetapi hanya ketika tiga keputusan terpisah selaras. Tunnel adalah transportasi, alamat dalam adalah tujuan, dan kebijakan menentukan siapa yang boleh mengetuk. Memperlakukan salah satunya sebagai jawaban menyeluruh menghasilkan keluhan yang lazim: host menjawab ping tetapi aplikasi tidak pernah terhubung. Perannya tidak sama, dan perbedaannya justru terletak di tempat pekerjaan desain berada.

Arah dial-in tidak mengatakan apa pun tentang arah layanan

Ketika klien memulai tunnel, ia membuka jalur yang dapat dipakai kedua arah setelah jalur itu ada. Apakah koneksi baru boleh masuk dari hub menuju klien tersebut adalah pertanyaan kebijakan gateway, bukan sifat orang yang melakukan dial. Pada hub OpenVPN yang dirutekan, misalnya, server memerlukan rute ke alamat dalam klien dan penerusan yang mengizinkan hubungan rekan.

Bayangkan sistem inventaris yang melakukan polling agen di laptop berpindah, atau pengembang yang membutuhkan API pengujian dari stasiun kerja di rumah. Keduanya ingin sisi kantor memulai percakapan, yang merupakan kebalikan dari pola klien-ke-server yang biasa.

Produk akses jarak jauh yang dihosting berbeda dalam hal ini, dan perbedaannya bukan bug. Beberapa VPN layanan terkelola sengaja memblokir koneksi tak diminta menuju klien yang terhubung karena model mereka adalah klien-ke-sumber, bukan sumber-ke-klien. Bacalah arsitektur produk yang didokumentasikan sebelum menjanjikan kepada kolega bahwa laptopnya dapat berperan sebagai server.

Ikuti jalur balasan sebelum membuka port

Jalur itu punya tiga bagian: rute di gateway yang menunjuk ke alamat dalam klien, kebijakan yang mengizinkan pemanggil tertentu, dan layanan yang mendengarkan di target. Setiap bagian gagal dengan cara berbeda, itulah sebabnya «VPN menyala» hampir tidak mengatakan apa pun.

Kabar baiknya, jalur dalam tidak memerlukan penerusan port di router rumah klien. Itulah inti menerbitkan layanan pada alamat tunnel alih-alih pada alamat WAN rumah, tempat paparan dan aturan NAT akan sangat berbeda. Router rumah juga dapat menolak hairpin koneksi yang datang dari kantor, sehingga rute WAN gagal karena alasan yang tidak berkaitan dengan VPN Anda. Menjaga lalu lintas di dalam tunnel menghindari kedua masalah sekaligus.

Periksa juga sisi target. Layanan yang hanya terikat ke 127.0.0.1 tidak dapat menerima koneksi yang tiba di antarmuka tunnel, seberapa pun benar rute gateway. Aturan firewall host yang hanya mengizinkan port dari subnet lokal juga akan menjatuhkan lalu lintas kantor, dan aturan itu tidak bergantung pada kebijakan VPN di atasnya.

Nama dan alamat adalah keputusan desain

Alamat di dalam tunnel tidak otomatis menjadi nama. Catatan DNS privat yang Anda kendalikan lebih jelas daripada berharap protokol penemuan melintasi tunnel, karena resolusi nama multicast tautan-lokal tetap di segmen lokal dan tidak menjadi DNS antar-subnet.

Stabilitas alamat sama pentingnya. Jika klien VPN mengambil dari kumpulan dengan sewa pendek, alamat dalam laptop berubah antar sesi dan setiap markah, cakupan firewall, serta pemeriksaan pemantauan yang dibangun di atasnya rusak diam-diam. Gunakan reservasi atau jalur pembaruan dinamis yang didokumentasikan.

Sepakati nama itu dengan pemilik identitas VPN, sehingga catatan, penetapan alamat, dan kebijakan akses berubah bersama, bukan dalam tiga tiket terpisah.

Uji layanannya, bukan keanggotaannya

Dari target, pastikan apa yang mendengarkan dan pada alamat mana, lalu pastikan pandangan gateway tentang jalur 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 sisi kantor dengan permintaan nyata alih-alih gema. curl yang berhasil ke layanan membuktikan rute, kebijakan, dan pendengar sekaligus, sedangkan ping yang berhasil hanya membuktikan bahwa ICMP diizinkan. Jika permintaan gagal, telusuri mundur melalui ketiga bagian alih-alih memperlebar firewall dan berharap.

Ketersediaan termasuk dalam percakapan yang sama. Laptop tidur, berpindah antar jaringan, dan terputus di penghujung hari. Layanan yang harus menjawab pada jam berapa pun tempatnya di host yang selalu menyala, sedangkan layanan upaya terbaik dapat tetap di klien dengan batasan itu dicatat.

Terbitkan sumber daya itu dengan sengaja, dengan nama, daftar pemanggil yang diizinkan, dan pemilik, dan perangkat jarak jauh menjadi layanan yang didukung alih-alih server yang tidak disengaja.