Prisijungta prie OpenVPN, bet nėra ping ar SMB bendrinimo? Patikrinkite trejus vartus

Tunelis pakyla, klientas gauna adresą, o tolimame LAN niekas neatsako. Ping nepavyksta, bendrinimas neatsidaro, o VPN žurnalas atrodo švarus, nes jo požiūriu sesija sveika. Tarp šios sesijos ir failo serveryje stovi treji nepriklausomi vartai: persiuntimo politika, paslaugai reikalingi prievadai ir vardas, kurį įvedėte vietoje adreso.

Kiekvieni vartai nepavyksta su skirtingu simptomu, ir tik pirmieji yra VPN serveryje.

Persiuntimas yra FORWARD grandinės politika

OpenVPN klausytojo priėmimas vyksta INPUT grandinėje, todėl tunelis gali prisijungti, nors kiekvienas į LAN nukreiptas paketas numetamas. tun0 atkeliaujantis ir per LAN sąsają išeinantis srautas praeina FORWARD, o hostas su numatytąja DROP politika ten jį tyliai numeta. Prieš ką nors kita liesdami patikrinkite ir sysctl, ir grandinę: sysctl net.ipv4.ip_forward ir iptables -L FORWARD -v -n.

Leiskite norimą kryptį ir jai priklausančius atsakymus, pavyzdžiui, accept taisyklę iš tunelio sąsajos į LAN sąsają ir stateful taisyklę established bei related srautui. Jei LAN yra už kito maršrutizatoriaus, tam maršrutizatoriui reikia grįžimo maršruto į klientų telkinį arba source NAT VPN serveryje. Patvirtinkite tą kelią vienu ping prieš pridėdami daugiau taisyklių, nes taisyklė, kurios neįmanoma pasiekti, niekada neatsiras skaitiklyje.

SMB reikia daugiau nei vieno prievado

Failų bendrinimas nėra viena TCP 445 pokalbis. Aptikimas naudoja UDP 137 ir 138, senesnės NetBIOS sesijos naudoja TCP 139, o šiuolaikinės SMB sesijos naudoja TCP 445. Taisyklė, kuri atveria tik 445, sukuria erziningą atvejį, kai priskirtas diskas veikia, o tinklo naršymas ne, arba atvirkščiai.

Dideli perdavimai per tunelį taip pat susiduria su MSS problemomis, kurios atrodo kaip sugadintas bendrinimas. SYN, kuris skelbia visą LAN segmento dydį, numetamas dėl mažesnio tunelio MTU, o ryšys pakimba po rankos paspaudimo. MSS priveržimas persiuntimo kelyje, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, pašalina šią strigimo klasę. Tikrinkite kelių megabaitų kopija, o ne katalogo sąrašu, nes maži atsakymai praeina net tada, kai dideli perdavimai nepraeina.

Tunelio adapteris atsiranda kaip naujas tinklo profilis

Windows priskiria kiekvieną adapterį tinklo profiliui, o naujas tunelio adapteris paprastai patenka į Public, kur failų ir spausdintuvų bendrinimo taisyklės užblokuotos. Tai failų serverio pagrindinio kompiuterio užkardos sprendimas, ne VPN serverio maršrutizavimo problema. Sąmoningai pakeiskite kategoriją komanda Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private patvirtinę, kad politika tai leidžia, nes kategorija taip pat keičia, kurios įeinančios taisyklės galioja.

Tas pats profilis paaiškina ping, kuris nepavyksta, nors TCP 445 pavyksta: echo užklausos Public profilyje numetamos pagal numatytuosius nustatymus.

Vardai patys neperžengia maršrutizuoto tunelio

NetBIOS vardų sprendimas ir vietinis aptikimas remiasi transliacijomis, kurių maršrutizuotas tunelis neneša. Todėl įvedus trumpą serverio vardą nepavyksta, nors jo adresas veikia, o bendrinimas atrodo sugadintas, kai sugadinta tik paieška. Pridėkite serverio DNS įrašą tame sprendiklyje, kurį duoda tunelis, arba naudokite adresą nuorodoje.

Jei diegimas vis dar priklauso nuo WINS, sukonfigūruokite jį kliente, o ne tikėkitės, kad atsiras transliacijos srautas. Pirmiausia testuokite adresu, kad vardo gedimas nebūtų sumaišytas su užkardos gedimu.

Testuokite po vieną sluoksnį ir skaitykite pirmą gedimą

Eikite aukštyn: ping tunelio tinklų sietuvą, ping LAN hostą adresu, tada atverkite paslaugos prievadą naudodami Test-NetConnection -ComputerName 10.8.0.5 -Port 445, ir tik tada autentifikuokitės bendrinime. Pirmas nepavykęs žingsnis yra sluoksnis, kurį reikia taisyti, o kiekvienas vėlesnis žingsnis yra triukšmas, kol tas nepraeina. Ping, kuris atsako, nors prievadas lieka uždarytas, nurodo paties failų serverio užkardą, o prievadas, kuris atsidaro nepaisant tylių ping, nurodo ICMP filtravimą. Užsirašykite pirmą nepavykusį žingsnį prieš ką nors keisdami, nes antras pakeitimas paslėps pirmojo rezultatą.

Jei VPN serveris nėra LAN maršrutizatorius, patvirtinkite grįžimo maršrutą tame maršrutizatoriuje prieš pridėdami serveryje daugiau taisyklių. Be jo užklausos pasiekia hostą, o atsakymai išeina numatytuoju maršrutu interneto link, kas iš kliento pusės atrodo lygiai kaip užkardos numetimas.

Laikykite bendrinimo paskyrą savo užrašuose atskirai nuo VPN prisijungimo, nes sėkmingas tunelis nieko nesako apie failų teises. SMB atvėrimas internetui, siekiant apeiti trūkstamą taisyklę, nėra sprendimas.