Поврзани сте со 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 интерфејсот плус stateful правило за established и related сообраќај. Ако 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, каде правилата за споделување датотеки и печатачи се блокирани. Тоа е одлука на домаќинскиот firewall на серверот за датотеки, не проблем со рутирање на VPN серверот. Свесно сменете ја категоријата со Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private откако ќе потврдите дека политиката го дозволува, зашто категоријата менува и кои влезни правила важат.

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

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

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

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

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

Одете нагоре: пингнете ја портата на тунелот, пингнете LAN домаќин по адреса, потоа отворете ја портата на услугата со Test-NetConnection -ComputerName 10.8.0.5 -Port 445, и само потоа автентицирајте се на споделувањето. Првиот чекор што не успева е слојот што треба да се поправи, а секој следен чекор е шум додека тој не помине. Ping што одговара додека портата останува затворена укажува на сопствениот firewall на серверот за датотеки, додека порта што се отвора и покрај тивки ping-ови укажува на ICMP филтрирање. Запишете го првиот неуспешен чекор пред да смените нешто, зашто втората промена го крие резултатот од првата.

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

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