Disambungkan ke OpenVPN tetapi tiada ping atau perkongsian SMB? Semak tiga pintu

Tunel naik, klien mendapat alamat, dan tiada apa pun di LAN jauh menjawab. Ping gagal, perkongsian tidak dibuka, dan log VPN kelihatan bersih kerana dari sudut pandangnya sesi itu sihat. Antara sesi itu dan fail pada pelayan terdapat tiga pintu bebas: dasar pemajuan, port yang diperlukan oleh perkhidmatan, dan nama yang anda taip sebagai ganti alamat.

Setiap pintu gagal dengan gejala berbeza, dan hanya yang pertama berada pada pelayan VPN.

Pemajuan ialah dasar pada rantaian FORWARD

Penerimaan pendengar OpenVPN berlaku pada INPUT, sebab itu tunel boleh bersambung walaupun setiap paket yang menuju LAN digugurkan. Trafik yang tiba di tun0 dan keluar melalui antara muka LAN melalui FORWARD, dan hos dengan dasar DROP lalai di situ membuangnya secara senyap. Semak kedua-dua sysctl dan rantaian sebelum menyentuh apa-apa lagi: sysctl net.ipv4.ip_forward dan iptables -L FORWARD -v -n.

Benarkan arah yang anda maksudkan dan balasan yang tergolong dengannya, contohnya peraturan accept dari antara muka tunel ke antara muka LAN serta peraturan stateful untuk trafik established dan related. Jika LAN berada di belakang penghala lain, penghala itu memerlukan laluan balik ke kolam klien atau source NAT pada pelayan VPN. Sahkan laluan itu dengan satu ping sebelum menambah peraturan lain, kerana peraturan yang tidak dapat dicapai tidak pernah muncul dalam pembilang.

SMB memerlukan lebih daripada satu port

Perkongsian fail bukan satu perbualan TCP 445. Penemuan menggunakan UDP 137 dan 138, sesi NetBIOS lama menggunakan TCP 139, dan sesi SMB moden menggunakan TCP 445. Peraturan yang hanya membuka 445 menghasilkan kes yang menyakitkan hati di mana pemacu yang dipetakan berfungsi dan pelayaran rangkaian tidak, atau sebaliknya.

Pemindahan besar melalui tunel juga menghadapi masalah MSS yang kelihatan seperti perkongsian rosak. SYN yang mengumumkan saiz segmen penuh LAN digugurkan oleh MTU tunel yang lebih kecil, dan sambungan tergantung selepas jabat tangan. Pengapitan MSS pada laluan pemajuan, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, menghapuskan jenis tersekat itu. Sahkan dengan salinan beberapa megabait dan bukan senarai direktori, kerana balasan kecil tetap melalui walaupun pemindahan besar tidak.

Penyesuai tunel datang sebagai profil rangkaian baharu

Windows mengelaskan setiap penyesuai ke dalam profil rangkaian, dan penyesuai tunel baharu biasanya mendarat di Public, tempat peraturan perkongsian fail dan pencetak disekat. Itu keputusan firewall hos pada pelayan fail, bukan masalah penghalaan pada pelayan VPN. Tukar kategori dengan sengaja menggunakan Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private selepas mengesahkan dasar membenarkannya, kerana kategori juga mengubah peraturan masuk mana yang terpakai.

Profil yang sama menjelaskan ping yang gagal sementara TCP 445 berjaya: permintaan gema digugurkan di Public secara lalai.

Nama tidak melintasi tunel yang dihalakan dengan sendirinya

Penyelesaian nama NetBIOS dan penemuan setempat bergantung pada siaran yang tidak dibawa oleh tunel yang dihalakan. Oleh itu menaip nama pendek pelayan gagal sementara alamatnya berfungsi, dan perkongsian kelihatan rosak apabila hanya carian yang rosak. Tambah rekod DNS untuk pelayan pada penyelesai yang diberikan tunel, atau gunakan alamat dalam pintasan.

Jika penggunaan masih bergantung pada WINS, konfigurasikannya pada klien dan bukan berharap trafik siaran muncul. Uji dahulu dengan alamat supaya kegagalan nama tidak disalah anggap sebagai kegagalan firewall.

Uji satu lapisan pada satu masa dan baca kegagalan pertama

Bergerak ke atas: ping get laluan tunel, ping hos LAN dengan alamat, kemudian buka port perkhidmatan dengan Test-NetConnection -ComputerName 10.8.0.5 -Port 445, dan hanya selepas itu sahkan identiti pada perkongsian. Langkah pertama yang gagal ialah lapisan yang perlu dibaiki, dan setiap langkah seterusnya ialah bunyi sehingga ia lulus. Ping yang menjawab sementara port kekal tertutup menunjukkan firewall pelayan fail itu sendiri, manakala port yang terbuka walaupun ping senyap menunjukkan penapisan ICMP. Catat langkah pertama yang gagal sebelum mengubah apa-apa, kerana perubahan kedua menyembunyikan hasil yang pertama.

Jika pelayan VPN bukan penghala LAN, sahkan laluan balik pada penghala itu sebelum menambah lebih banyak peraturan pada pelayan. Tanpanya, permintaan sampai ke hos dan balasan keluar melalui laluan lalai menuju internet, yang dari sisi klien kelihatan tepat seperti guguran firewall.

Simpan akaun perkongsian berasingan daripada log masuk VPN dalam nota anda, kerana tunel yang berjaya tidak memberitahu apa-apa tentang kebenaran fail. Mendedahkan SMB ke internet untuk mengelak peraturan yang hilang bukan penyelesaian.