Konektita al OpenVPN sed sen ping aŭ SMB-kunhavigo? Kontrolu tri pordegojn

La tunelo ekfunkcias, la kliento ricevas adreson, kaj nenio en la fora LAN respondas. Ping malsukcesas, la kunhavigo ne malfermiĝas, kaj la VPN-protokolo aspektas pura, ĉar el ĝia vidpunkto la sesio estas sana. Inter tiu sesio kaj dosiero sur servilo staras tri sendependaj pordegoj: la plusenda politiko, la pordoj kiujn la servo bezonas, kaj la nomo, kiun vi tajpis anstataŭ adreso.

Ĉiu pordego malsukcesas per alia simptomo, kaj nur la unua estas sur la VPN-servilo.

Plusendado estas politiko sur la FORWARD-ĉeno

La akcepto de la OpenVPN-aŭskultanto okazas sur INPUT, pro tio la tunelo povas konektiĝi dum ĉiu paketo celanta la LAN-on estas forĵetata. Trafiko kiu alvenas sur tun0 kaj forlasas tra la LAN-interfaco trapasas FORWARD, kaj gastiganto kun defaŭlta DROP-politiko tie forĵetas ĝin silente. Kontrolu kaj la sysctl kaj la ĉenon antaŭ ol tuŝi ion ajn alian: sysctl net.ipv4.ip_forward kaj iptables -L FORWARD -v -n.

Permesu la direkton kiun vi intencas kaj la respondojn kiuj apartenas al ĝi, ekzemple accept-regulo de la tunela interfaco al la LAN-interfaco kaj stateful-regulo por established kaj related trafiko. Se la LAN estas malantaŭ alia enkursigilo, tiu enkursigilo bezonas vojon reen al la klienta baseno aŭ source NAT sur la VPN-servilo. Konfirmu tiun vojon per unu ping antaŭ ol aldoni pliajn regulojn, ĉar regulo al kiu oni ne povas atingi neniam aperas en nombrilo.

SMB bezonas pli ol unu pordon

Dosiera kunhavigo ne estas unu sola TCP 445-interparolo. Malkovrado uzas UDP 137 kaj 138, pli malnovaj NetBIOS-sesioj uzas TCP 139, kaj modernaj SMB-sesioj uzas TCP 445. Regulo kiu malfermas nur 445 kreas la frustran kazon en kiu mapita disko funkcias kaj retumado de la reto ne, aŭ inverse.

Grandaj transigoj tra tunelo ankaŭ trafas MSS-problemojn kiuj aspektas kiel rompita kunhavigo. SYN kiu anoncas la plenan segmentgrandon de la LAN estas forĵetata de la pli malgranda MTU de la tunelo, kaj la konekto pendas post la manpremo. Limigado de MSS sur la plusenda vojo, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, forigas tiun klason de haltiĝo. Kontrolu per kopio de kelkaj megabajtoj anstataŭ per dosieruja listo, ĉar malgrandaj respondoj pasas eĉ kiam amasaj transigoj ne pasas.

La tunela adaptilo alvenas kiel nova retprofilaro

Windows klasifikas ĉiun adaptilon en retprofilaron, kaj freŝa tunela adaptilo kutime surteriĝas en Public, kie la reguloj por dosiera kaj presila kunhavigo estas blokitaj. Tio estas decido de la gastiganta fajroŝirmilo sur la dosierservilo, ne enkursiga problemo sur la VPN-servilo. Ŝanĝu la kategorion intence per Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private post kiam vi konfirmos ke la politiko permesas tion, ĉar la kategorio ankaŭ ŝanĝas kiuj envenaj reguloj validas.

La sama profilo klarigas ping kiu malsukcesas dum TCP 445 sukcesas: eĥopetoj estas forĵetataj en Public defaŭlte.

Nomoj ne trapasas enkursigitan tunelon per si mem

NetBIOS-nomrezolvo kaj loka malkovrado dependas de dissendoj kiujn enkursigita tunelo ne portas. Tajpi la mallongan nomon de la servilo do malsukcesas dum ĝia adreso funkcias, kaj la kunhavigo aspektas rompita kiam nur la serĉado estas. Aldonu DNS-rikan por la servilo ĉe la solvilo kiun la tunelo donas, aŭ uzu la adreson en la ŝparvojo.

Se la instalado ankoraŭ dependas de WINS, agordu ĝin sur la kliento anstataŭ esperi ke dissenda trafiko aperos. Testu unue per adreso por ke nomfiasko ne estu konfuzita kun fajroŝirmila fiasko.

Testu unu tavolon samtempe kaj legu la unuan fiaskon

Iru supren: pingu la tunelan enirejon, pingu LAN-gastiganton per adreso, poste malfermu la servan pordon per Test-NetConnection -ComputerName 10.8.0.5 -Port 445, kaj nur poste aŭtentigu vin al la kunhavigo. La unua paŝo kiu malsukcesas estas la tavolo por ripari, kaj ĉiu posta paŝo estas bruo ĝis ĝi pasos. Ping kiu respondas dum la pordo restas fermita indikas la propran fajroŝirmilon de la dosierservilo, dum pordo kiu malfermiĝas malgraŭ silentaj pingoj indikas ICMP-filtradon. Notu la unuan malsukcesan paŝon antaŭ ol ŝanĝi ion ajn, ĉar dua ŝanĝo kaŝas la rezulton de la unua.

Se la VPN-servilo ne estas la enkursigilo de la LAN, konfirmu la reiran vojon sur tiu enkursigilo antaŭ ol aldoni pliajn regulojn al la servilo. Sen tio petoj atingas la gastiganton kaj respondoj forlasas per la defaŭlta vojo al la interreto, kio de la klienta flanko aspektas ĝuste kiel fajroŝirmila forĵeto.

Tenu la kunhavigan konton aparte de la VPN-saluto en viaj notoj, ĉar sukcesa tunelo diras nenion pri dosierpermesoj. Elmeti SMB al la interreto por eviti mankantan regulon ne estas solvo.