Terhubung ke OpenVPN tetapi tidak ada ping atau berbagi SMB? Periksa tiga gerbang

Tunnel menyala, klien mendapat alamat, dan tidak ada yang menjawab di LAN jauh. Ping gagal, berbagi tidak terbuka, dan log VPN tampak bersih karena dari sudut pandangnya sesi itu sehat. Antara sesi itu dan berkas di server ada tiga gerbang independen: kebijakan penerusan, port yang dibutuhkan layanan, dan nama yang Anda ketik sebagai ganti alamat.

Setiap gerbang gagal dengan gejala berbeda, dan hanya yang pertama ada di server VPN.

Penerusan adalah kebijakan pada rantai FORWARD

Penerimaan listener OpenVPN terjadi di INPUT, itulah sebabnya tunnel bisa terhubung sementara setiap paket yang menuju LAN dibuang. Lalu lintas yang datang di tun0 dan keluar melalui antarmuka LAN melewati FORWARD, dan host dengan kebijakan DROP bawaan di sana membuangnya diam-diam. Periksa sysctl dan rantainya sebelum menyentuh hal lain: sysctl net.ipv4.ip_forward dan iptables -L FORWARD -v -n.

Izinkan arah yang Anda maksud dan balasan yang termasuk di dalamnya, misalnya aturan accept dari antarmuka tunnel ke antarmuka LAN plus aturan stateful untuk lalu lintas established dan related. Jika LAN berada di belakang router lain, router itu perlu rute kembali ke kumpulan klien atau source NAT di server VPN. Pastikan jalur itu dengan satu ping sebelum menambah aturan lain, karena aturan yang tidak bisa dijangkau tidak pernah muncul di penghitung.

SMB butuh lebih dari satu port

Berbagi berkas bukanlah satu percakapan TCP 445. Penemuan memakai UDP 137 dan 138, sesi NetBIOS lama memakai TCP 139, dan sesi SMB modern memakai TCP 445. Aturan yang hanya membuka 445 menciptakan kasus menjengkelkan ketika drive yang dipetakan berfungsi dan penjelajahan jaringan tidak, atau sebaliknya.

Transfer besar melalui tunnel juga menabrak masalah MSS yang tampak seperti berbagi rusak. SYN yang mengumumkan ukuran segmen penuh LAN dibuang oleh MTU tunnel yang lebih kecil, dan koneksi menggantung setelah jabat tangan. Pembatasan MSS di jalur penerusan, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, menghilangkan jenis kemacetan itu. Verifikasi dengan salinan beberapa megabyte alih-alih daftar direktori, karena balasan kecil tetap lolos meski transfer besar tidak.

Adaptor tunnel datang sebagai profil jaringan baru

Windows mengklasifikasikan setiap adaptor ke dalam profil jaringan, dan adaptor tunnel baru biasanya mendarat di Public, tempat aturan berbagi berkas dan printer diblokir. Itu keputusan firewall host di server berkas, bukan masalah perutean di server VPN. Ubah kategori dengan sengaja memakai Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private setelah memastikan kebijakan mengizinkannya, karena kategori juga mengubah aturan masuk mana yang berlaku.

Profil yang sama menjelaskan ping yang gagal sementara TCP 445 berhasil: permintaan echo dibuang di Public secara bawaan.

Nama tidak menyeberangi tunnel yang dirutekan dengan sendirinya

Resolusi nama NetBIOS dan penemuan lokal bergantung pada siaran yang tidak dibawa tunnel yang dirutekan. Karena itu mengetik nama pendek server gagal sementara alamatnya berfungsi, dan berbagi tampak rusak padahal hanya pencariannya yang rusak. Tambahkan catatan DNS untuk server di resolver yang diberikan tunnel, atau gunakan alamatnya di pintasan.

Jika penerapan masih bergantung pada WINS, konfigurasikan di klien alih-alih berharap lalu lintas siaran muncul. Uji dulu dengan alamat agar kegagalan nama tidak dikira kegagalan firewall.

Uji satu lapisan sekaligus dan baca kegagalan pertama

Naik ke atas: ping gateway tunnel, ping host LAN dengan alamat, lalu buka port layanan dengan Test-NetConnection -ComputerName 10.8.0.5 -Port 445, dan baru setelah itu autentikasi ke berbagi. Langkah pertama yang gagal adalah lapisan yang harus diperbaiki, dan setiap langkah berikutnya hanya kebisingan sampai langkah itu lolos. Ping yang menjawab sementara port tetap tertutup menunjuk ke firewall server berkas itu sendiri, sedangkan port yang terbuka meski ping senyap menunjuk ke penyaringan ICMP. Catat langkah pertama yang gagal sebelum mengubah apa pun, karena perubahan kedua menyembunyikan hasil yang pertama.

Jika server VPN bukan router LAN, pastikan rute kembali di router itu sebelum menambah aturan lain di server. Tanpanya, permintaan sampai ke host dan balasan keluar lewat rute bawaan menuju internet, yang dari sisi klien tampak persis seperti pembuangan firewall.

Simpan akun berbagi terpisah dari login VPN dalam catatan Anda, karena tunnel yang berhasil tidak menjelaskan apa pun tentang izin berkas. Mengekspos SMB ke internet untuk menghindari aturan yang hilang bukanlah solusi.