Свързани сте с 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 имена и локалното откриване разчитат на broadcast, които маршрутизиран тунел не пренася. Затова въвеждането на краткото име на сървъра се проваля, докато адресът му работи, и споделянето изглежда счупено, когато само търсенето е такова. Добавете DNS запис за сървъра в резолвера, който тунелът раздава, или използвайте адреса в прекия път.

Ако внедряването все още зависи от WINS, конфигурирайте го на клиента, вместо да се надявате, че broadcast трафикът ще се появи. Тествайте първо по адрес, за да не се обърка отказ на име с отказ на файъруол.

Тествайте един слой наведнъж и четете първия отказ

Движете се нагоре: ping на тунелния шлюз, ping на LAN хост по адрес, после отворете порта на услугата с Test-NetConnection -ComputerName 10.8.0.5 -Port 445 и едва след това се автентикирайте в споделянето. Първата стъпка, която се провали, е слоят за поправяне, а всяка следваща стъпка е шум, докато не мине. Ping, който отговаря, докато портът остава затворен, сочи към собствения файъруол на файловия сървър, а порт, който се отваря въпреки тихите ping, сочи към филтриране на ICMP. Запишете първата провалена стъпка, преди да промените нещо, защото втора промяна скрива резултата от първата.

Ако VPN сървърът не е рутерът на LAN, потвърдете обратния маршрут на този рутер, преди да добавяте още правила към сървъра. Без него заявките стигат до хоста, а отговорите излизат по маршрута по подразбиране към интернет, което от страна на клиента изглежда точно като изхвърляне от файъруол.

Пазете акаунта за споделяне отделно от VPN входа в бележките си, защото успешният тунел не казва нищо за файловите разрешения. Излагането на SMB в интернет, за да се заобиколи липсващо правило, не е решение.