Nakakonekta sa OpenVPN pero walang ping o SMB share? Suriin ang tatlong tarangkahan

Bumangon ang tunnel, nakakuha ng address ang client, at walang sumasagot sa malayong LAN. Nabibigo ang ping, hindi bumubukas ang share, at mukhang malinis ang log ng VPN dahil sa pananaw nito ay malusog ang session. Sa pagitan ng session na iyon at ng file sa isang server ay may tatlong malayang tarangkahan: ang patakaran sa pagpapasa, ang mga port na kailangan ng serbisyo, at ang pangalang itinaip mo sa halip na address.

Bawat tarangkahan ay nabibigo sa ibang sintomas, at ang una lamang ang nasa server ng VPN.

Ang pagpapasa ay isang patakaran sa chain na FORWARD

Ang pagtanggap sa listener ng OpenVPN ay nangyayari sa INPUT, kaya nakakonekta ang tunnel habang itinatapon ang bawat packet na patungo sa LAN. Ang trapikong dumarating sa tun0 at lumalabas sa interface ng LAN ay dumadaan sa FORWARD, at ang host na may default na patakarang DROP doon ay tahimik na itinatapon ito. Bago hawakan ang anumang iba, suriin ang sysctl at ang chain: sysctl net.ipv4.ip_forward at iptables -L FORWARD -v -n.

Payagan ang direksyong gusto mo at ang mga sagot na kabilang dito, halimbawa isang panuntunang accept mula sa interface ng tunnel patungo sa interface ng LAN kasama ang isang panuntunang stateful para sa trapikong established at related. Kung ang LAN ay nasa likod ng ibang router, kailangan ng router na iyon ng rutang pabalik sa pool ng client o source NAT sa server ng VPN. Kumpirmahin ang landas na iyon sa isang ping bago magdagdag ng mas maraming panuntunan, dahil ang panuntunang hindi maabot ay hindi kailanman lumilitaw sa counter.

Ang SMB ay nangangailangan ng higit sa isang port

Ang pagbabahagi ng file ay hindi isang usapan lamang sa TCP 445. Gumagamit ng UDP 137 at 138 ang pagtuklas, gumagamit ng TCP 139 ang mas lumang session ng NetBIOS, at gumagamit ng TCP 445 ang makabagong session ng SMB. Ang panuntunang nagbubukas lamang ng 445 ay lumilikha ng nakakainis na kaso kung saan gumagana ang naka-map na drive at hindi ang pag-browse sa network, o kabaliktaran.

Ang malalaking paglilipat sa tunnel ay tumatama rin sa mga problema sa MSS na mukhang sirang share. Ang SYN na nagtatanghal ng buong laki ng segment ng LAN ay itinatapon ng mas maliit na MTU ng tunnel, at nakabitin ang koneksyon pagkatapos ng handshake. Ang pag-clamp ng MSS sa landas ng pagpapasa, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, ay nag-aalis ng ganoong uri ng pagtigil. Beripikahin gamit ang kopya ng ilang megabyte sa halip na listahan ng direktoryo, dahil dumadaan ang maliliit na sagot kahit hindi dumadaan ang malalaking paglilipat.

Dumarating ang adapter ng tunnel bilang bagong profile ng network

Iniuuri ng Windows ang bawat adapter sa isang profile ng network, at ang bagong adapter ng tunnel ay karaniwang napupunta sa Public, kung saan naka-block ang mga panuntunan sa pagbabahagi ng file at printer. Iyon ay desisyon ng firewall ng host sa server ng file, hindi problema sa routing sa server ng VPN. Sadyaing palitan ang kategorya gamit ang Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private pagkatapos kumpirmahing pinapayagan ito ng patakaran, dahil binabago rin ng kategorya kung aling mga panuntunan sa papasok ang nalalapat.

Ipinapaliwanag ng parehong profile ang ping na nabibigo habang nagtatagumpay ang TCP 445: itinatapon ang mga kahilingang echo sa Public bilang default.

Hindi tumatawid nang mag-isa ang mga pangalan sa isang rutadong tunnel

Ang paglutas ng pangalan ng NetBIOS at lokal na pagtuklas ay umaasa sa mga broadcast na hindi dinadala ng rutadong tunnel. Kaya nabibigo ang pagtaip ng maikling pangalan ng server habang gumagana ang address nito, at mukhang sira ang share kung ang paghahanap lamang ang sira. Magdagdag ng talaan ng DNS para sa server sa resolver na ibinibigay ng tunnel, o gamitin ang address sa shortcut.

Kung ang deployment ay umaasa pa rin sa WINS, isaayos ito sa client sa halip na umasa na lalabas ang trapikong broadcast. Subukan muna sa address upang ang pagkabigo ng pangalan ay hindi mapagkamalang pagkabigo ng firewall.

Subukan ang isang layer sa isang pagkakataon at basahin ang unang pagkabigo

Umakyat: i-ping ang gateway ng tunnel, i-ping ang host ng LAN sa address, pagkatapos buksan ang port ng serbisyo gamit ang Test-NetConnection -ComputerName 10.8.0.5 -Port 445, at pagkatapos lamang magpatotoo sa share. Ang unang hakbang na nabibigo ang layer na dapat ayusin, at ang bawat sumunod na hakbang ay ingay hanggang pumasa iyon. Ang ping na sumasagot habang nakasara ang port ay tumutukoy sa sariling firewall ng server ng file, samantalang ang port na bumubukas sa kabila ng tahimik na ping ay tumutukoy sa pagsasala ng ICMP. Isulat ang unang hakbang na nabibigo bago magbago ng anuman, dahil ikinukubli ng ikalawang pagbabago ang resulta ng una.

Kung ang server ng VPN ay hindi ang router ng LAN, kumpirmahin ang rutang pabalik sa router na iyon bago magdagdag ng mas maraming panuntunan sa server. Kung wala iyon, umaabot ang mga kahilingan sa host at lumalabas ang mga sagot sa default na ruta patungo sa internet, na mula sa panig ng client ay eksaktong mukhang pagtatapon ng firewall.

Panatilihing hiwalay ang account ng share sa pag-log in sa VPN sa iyong mga tala, dahil ang matagumpay na tunnel ay walang sinasabi tungkol sa mga pahintulot sa file. Ang paglalantad ng SMB sa internet upang iwasan ang kulang na panuntunan ay hindi solusyon.