Повезани сте са OpenVPN-ом, али нема пинга ни SMB дељења? Проверите три капије

Тунел се подигне, клијент добије адресу, а ништа на удаљеном LAN-у не одговара. Пинг не успева, дељење се не отвара, а VPN дневник изгледа чист јер је из његове перспективе сесија здрава. Између те сесије и датотеке на серверу стоје три независне капије: политика прослеђивања, портови који су услузи потребни и име које сте уписали уместо адресе.

Свака капија пада с другачијим симптомом, а само је прва на VPN серверу.

Прослеђивање је политика на FORWARD ланцу

Прихватање OpenVPN слушаоца дешава се на INPUT-у, зато се тунел може повезати док се сваки пакет усмерен ка LAN-у одбацује. Саобраћај који долази на tun0 и одлази преко LAN интерфејса пролази кроз FORWARD, а хост са подразумеваном DROP политиком тамо га тихо одбацује. Пре него што дотакнете било шта друго, проверите и sysctl и ланац: sysctl net.ipv4.ip_forward и iptables -L FORWARD -v -n.

Дозволите смер који желите и одговоре који му припадају, на пример accept правило од интерфејса тунела ка LAN интерфејсу плус stateful правило за established и related саобраћај. Ако LAN стоји иза другог рутера, том рутеру треба рута назад ка базену клијената или source NAT на VPN серверу. Потврдите тај пут једним пингом пре додавања нових правила, јер правило до којег се не може доћи никада се не појављује у бројачу.

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, где су правила за дељење датотека и штампача блокирана. То је одлука хост firewall-а на серверу датотека, а не проблем рутирања на VPN серверу. Намерно промените категорију помоћу Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private након што потврдите да то политика дозвољава, јер категорија мења и то која улазна правила важе.

Исти профил објашњава пинг који не успева док TCP 445 успева: echo захтеви се на Public профилу подразумевано одбацују.

Имена сама не прелазе рутирани тунел

NetBIOS разрешавање имена и локално откривање ослањају се на broadcast саобраћај који рутирани тунел не преноси. Зато уписивање кратког имена сервера не успева док његова адреса ради, а дељење изгледа покварено када је покварен само lookup. Додајте DNS запис за сервер на resolver који тунел даје или користите адресу у пречици.

Ако се примена још ослања на WINS, конфигуришите га на клијенту уместо да се надате broadcast саобраћају. Прво тестирајте адресом како се квар имена не би заменио с кваром firewall-а.

Тестирајте један слој по један и читајте први квар

Идите одоздо према горе: пинг-ујте тунелски gateway, пинг-ујте LAN хост адресом, затим отворите порт услуге са Test-NetConnection -ComputerName 10.8.0.5 -Port 445, и тек онда се аутентификујте на дељењу. Први корак који падне је слој који треба поправити, а сваки каснији корак је шум док тај не прође. Пинг који одговара док порт остаје затворен упућује на властити firewall сервера датотека, а порт који се отвори упркос тихим пинговима упућује на ICMP филтрирање. Запишите први корак који пада пре него што било шта промените, јер друга промена крије резултат прве.

Ако VPN сервер није рутер LAN-а, потврдите повратну руту на том рутеру пре него што серверу додате још правила. Без ње захтеви стижу до хоста, а одговори одлазе подразумеваном рутом ка интернету, што са клијентске стране изгледа тачно као firewall drop.

У својим белешкама држите налог за дељење одвојено од VPN пријаве, јер успешан тунел не говори ништа о дозволама за датотеке. Излагање SMB-а интернету да бисте избегли правило које недостаје није решење.