Mengapa alamat tunnel VPN Anda tidak membuka port masuk
Alamat tunnel mengidentifikasi klien Anda kepada peer yang dapat merutekan ke sana, dan tidak pernah membuat pendengar. Periksa pengikatan, rute balik, lalu kebijakan.
Sambungkan ke VPN kantor, jalankan layanan kecil pada port 8443, kirim alamat tunnel kepada rekan kerja, dan lihat koneksi gagal sementara klien tetap melaporkan terhubung. Tidak ada yang rusak di tunnel: alamat sudah diberikan, sesi aktif, dan paket yang seharusnya membawa jawaban sama sekali tidak pernah diizinkan. Lakukan tiga pemeriksaan di bawah ini secara berurutan dan berhenti pada yang gagal, karena masing-masing punya perbaikan berbeda dan hanya satu di antaranya soal VPN.
Mulai dari tempat socket benar-benar diikat
Sebelum apa pun dirutekan, sesuatu harus mendengarkan pada alamat yang dapat dijangkau pemanggil. Server pengembangan adalah tersangka biasa, karena banyak dari mereka secara default mengikat ke loopback dan hanya menerima koneksi yang berasal dari mesin yang sama. Alamat tunnel tidak mengubah pengikatan itu, dan sistem operasi akan menolak koneksi jauh sebelum VPN terlibat.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Baca kolom alamat lokal, bukan statusnya. 127.0.0.1:8443 berarti hanya loopback, dan perbaikannya adalah mengikat ke 0.0.0.0 atau ke alamat tunnel itu sendiri. 0.0.0.0:8443 menerima di semua antarmuka, yang lebih luas daripada yang dimaksud kebanyakan orang ketika mesin juga punya alamat publik; 10.64.7.15:8443 adalah versi sempit yang hanya mendengarkan di tempat rekan kerja dapat menjangkau. Perhatikan juga nama proses pada keluaran yang sama, karena instans tersisa dari uji sebelumnya adalah penyebab umum port tampak terbuka dan menjawab dengan isi yang salah.
Lalu tanyakan apakah ada yang dapat merutekan ke alamat itu
Alamat tunnel hanya bermakna bagi peer yang dikonfigurasi untuk mengirim prefiks itu ke dalam tunnel. Mesin rekan kerja punya tabelnya sendiri, dan jika tidak ada rute ke subnet tunnel, paket pergi ke gateway default dan mati di tempat yang tidak tahu alamat itu ada. Ini pertanyaan perutean di sisi pemanggil, bukan izin di sisi Anda.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Server di antara kedua klien sama pentingnya. Dalam desain akses jarak jauh yang umum, setiap klien membuka koneksi keluar ke gateway dan gateway menyimpan status aliran tersebut, sehingga balasan kembali melalui jalur yang sudah dikenalnya. Koneksi dari satu klien ke klien lain adalah aliran baru yang harus diterima dan diteruskan gateway, dan banyak penerapan mematikannya dengan sengaja agar klien tetap terisolasi satu sama lain. Layanan VPN konsumen biasanya mengisolasi secara default; gateway korporat kadang mengizinkannya per grup.
Periksa arahnya sebelum mengubah apa pun di host. Jika alamat tunnel menjawab dari gateway itu sendiri tetapi tidak dari peer, pengaturan klien-ke-klien gateway adalah pembedanya, dan tidak ada penyuntingan firewall lokal yang dapat menggantikannya.
Terakhir, temukan kebijakan yang mengizinkan aliran
Tiga lapisan kebijakan berada di antara paket yang dirutekan dan layanan yang menjawab: keputusan penerusan server VPN, firewall host, dan grup keamanan cloud apa pun di depan instans. Ketiganya harus sepakat, dan mereka gagal dengan cara berbeda, karena itu gejala pada tabel di atas lebih berguna daripada pesan galat di peramban.
Firewall host adalah lapisan yang orang lupakan setelah pengikatan berhasil, karena aturan yang mengizinkan port pada antarmuka LAN tidak otomatis mengizinkannya pada antarmuka tunnel. Aturan yang dibatasi antarmuka adalah desain yang benar dan juga penyebab umum layanan yang berfungsi dari kantor tetapi tidak dari rumah. Baca cakupan aturannya, bukan nomor portnya.
Penyaringan stateful menjelaskan kasus sebaliknya. Koneksi keluar dari laptop Anda menciptakan status, dan balasannya diizinkan tanpa aturan masuk. Koneksi rekan kerja adalah aliran yang benar-benar baru tanpa status di belakangnya, jadi perlu izin eksplisit. Asimetri itulah seluruh alasan sesi peramban yang berfungsi di mesin Anda sendiri tidak mengatakan apa pun tentang apakah layanan dapat dijangkau dari luar.
Ketika satu pemeriksaan gagal, ubah desainnya, bukan tunnelnya
Jika syaratnya adalah rekan kerja membuka layanan lokal Anda, jawaban jujurnya biasanya mekanisme yang dibangun untuk akses masuk. Tunnel SSH terbalik adalah yang terkecil: mesin Anda terhubung keluar ke host yang sudah dapat dijangkau rekan kerja, dan pendengar berada di host itu.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Relay memerlukan GatewayPorts clientspecified dalam konfigurasi server SSH-nya, jika tidak pendengar yang diteruskan mengikat ke loopback di relay dan rekan kerja mengalami penolakan yang sama seperti sebelumnya. Untuk apa pun yang bertahan lebih dari satu sore, penyeimbang beban atau ingress dengan pemeriksaan kesehatan dan sertifikat untuk nama yang dipublikasikan adalah alat yang lebih baik, dan tunnel situs-ke-situs dengan rute untuk kedua subnet adalah jawaban yang tepat ketika dua jaringan benar-benar perlu berbicara.
Setiap desain itu membuat paparan menjadi eksplisit, dan itulah intinya. VPN memindahkan paket di antara jaringan yang sudah Anda berwenang gunakan; ia tidak menerbitkan layanan dan tidak mengubah laptop menjadi host yang menghadap internet. Tugasnya adalah memutuskan lapisan mana dari ketiganya yang diubah, dan tunnel jarang menjadi salah satunya.