Падключыліся да OpenVPN, але няма ping ці SMB-доступу? Праверце тры брамы

Тунель узнімаецца, кліент атрымлівае адрас, і нішто ў далёкай LAN не адказвае. Ping не праходзіць, доступ не адкрываецца, а журнал VPN выглядае чыстым, бо з яго пункту гледжання сеанс здаровы. Паміж гэтым сеансам і файлам на серверы стаяць тры незалежныя брамы: палітыка перанакіравання, порты, патрэбныя службе, і імя, якое вы ўвялі замест адраса.

Кожная брама адмаўляе з іншым сімптомам, і толькі першая знаходзіцца на серверы VPN.

Перанакіраванне — гэта палітыка на ланцугу FORWARD

Прыём слухача OpenVPN адбываецца на INPUT, таму тунель можа падключыцца, пакуль кожны пакет, накіраваны ў LAN, адкідаецца. Трафік, які прыходзіць на tun0 і выходзіць праз інтэрфейс LAN, праходзіць праз FORWARD, і хост з палітыкай DROP па змаўчанні там маўкліва яго адкідвае. Праверце і sysctl, і ланцуг, перш чым чапаць што-небудзь яшчэ: sysctl net.ipv4.ip_forward і iptables -L FORWARD -v -n.

Дазвольце патрэбны вам кірунак і адказы, што да яго належаць, напрыклад правіла accept ад інтэрфейса тунеля да інтэрфейса LAN плюс правіла са станам для ўсталяванага і звязанага трафіку. Калі LAN знаходзіцца за іншым маршрутызатарам, гэтаму маршрутызатару патрэбны маршрут назад да пула кліентаў або source NAT на серверы VPN. Пацвердзіце гэты шлях адным ping, перш чым дадаваць новыя правілы, бо правіла, да якога немагчыма дабрацца, ніколі не з'явіцца ў лічыльніку.

SMB патрэбны больш за адзін порт

Агульны доступ да файлаў — гэта не адзіная размова TCP 445. Выяўленне выкарыстоўвае UDP 137 і 138, старыя сеансы NetBIOS — TCP 139, а сучасныя сеансы SMB — TCP 445. Правіла, якое адкрывае толькі 445, стварае раздражняльны выпадак, калі падключаны дыск працуе, а прагляд сеткі — не, або наадварот.

Вялікія перадачы праз тунель таксама трапляюць на праблемы MSS, якія выглядаюць як зламаны доступ. SYN, які аб'яўляе поўны памер сегмента LAN, адкідаецца меншым MTU тунеля, і злучэнне завісае пасля рукапаціскання. Абмежаванне MSS на шляху перанакіравання, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, прыбірае гэты клас завісанняў. Правярайце капіяваннем некалькіх мегабайт, а не спісам каталога, бо малыя адказы праходзяць нават тады, калі масавыя перадачы не.

Адаптар тунеля прыходзіць як новы сеткавы профіль

Windows класіфікуе кожны адаптар у сеткавы профіль, і новы адаптар тунеля звычайна трапляе ў Public, дзе правілы агульнага доступу да файлаў і прынтараў заблакаваныя. Гэта рашэнне хост-брандмаўэра на файлавым серверы, а не праблема маршрутызацыі на серверы VPN. Змяніце катэгорыю свядома з дапамогай Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private пасля таго, як пераканаецеся, што палітыка гэта дазваляе, бо катэгорыя таксама змяняе, якія ўваходныя правілы дзейнічаюць.

Той жа профіль тлумачыць ping, які не праходзіць, пакуль TCP 445 паспяховы: запыты рэха па змаўчанні адкідаюцца ў Public.

Імёны самі не перасякаюць маршрутызаваны тунель

Развязанне імёнаў NetBIOS і лакальнае выяўленне абапіраюцца на шырокавяшчальныя пакеты, якія маршрутызаваны тунель не пераносіць. Таму ўвод кароткага імя сервера не працуе, пакуль яго адрас працуе, і доступ выглядае зламаным, хаця зламаны толькі пошук. Дадайце DNS-запіс для сервера ў рэзалвер, які выдае тунель, або выкарыстоўвайце адрас у ярлыку.

Калі разгортванне ўсё яшчэ залежыць ад WINS, наладзьце яго на кліенце, а не спадзейцеся, што шырокавяшчальны трафік з'явіцца. Спачатку правярайце па адрасе, каб збой імя не прынялі за збой брандмаўэра.

Правярайце па адным узроўні і чытайце першы збой

Рухайцеся ўверх: ping шлюза тунеля, ping хоста LAN па адрасе, затым адкрыйце порт службы з дапамогай Test-NetConnection -ComputerName 10.8.0.5 -Port 445, і толькі пасля гэтага аўтэнтыфікуйцеся ў доступе. Першы крок, які не прайшоў, — гэта ўзровень, які трэба выправіць, і кожны наступны крок — шум, пакуль ён не пройдзе. Ping, які адказвае, пакуль порт застаецца зачыненым, паказвае на ўласны брандмаўэр файлавага сервера, а порт, які адкрываецца нягледзячы на маўклівыя ping, — на фільтраванне ICMP. Запішыце першы крок, які не прайшоў, перш чым нешта змяняць, бо другая змена хавае вынік першай.

Калі сервер VPN не з'яўляецца маршрутызатарам LAN, пацвердзіце зваротны маршрут на гэтым маршрутызатары, перш чым дадаваць серверу новыя правілы. Без яго запыты дасягаюць хоста, а адказы выходзяць па маршруце па змаўчанні ў інтэрнэт, што з боку кліента выглядае як разрыў брандмаўэра.

Трымайце ўліковы запіс доступу асобна ад лагіна VPN у сваіх нататках, бо паспяховы тунель нічога не кажа пра правы на файлы. Адкрыццё SMB у інтэрнэт, каб абысці адсутнае правіла, — не рашэнне.