Достъпът до LAN през OpenVPN е счупен? Проверете зони, маршрути и обратен път

Тунелът съобщава за успешна връзка, собствената страница на рутера се зарежда, а свързването на диск към машина зад него все още изтича. В тази комбинация няма противоречие: рутерът отговаря като себе си, а достигането на нещо зад него е друго решение, взето на друго място. Изпълнете проверките по-долу по ред и спрете при първия провал, защото всяка се опира на предишната. Когато и четирите минат, повредата е над тунела, а не в него.

Кой филтър вижда пакет, насочен към LAN

Пакет, адресиран до рутера, се консумира локално; пакет, адресиран до хост зад него, трябва да бъде препратен, а защитните стени съдят тези два случая поотделно. Затова разрешението да стигнете до рутера не казва нищо за разрешението да го пресечете. Фърмуерът, който крие наборите си от правила, все пак прилага и двете, обикновено като селектор с LAN, интернет или и двете. Ако селекторът пропуска LAN, никоя следваща проверка няма да има значение.

OpenWrt прави разделянето проверимо и разликата си струва да се прочете веднъж. Зоната, която завършва тунела, се нуждае от правило за препращане към LAN зоната, докато правилото за вход управлява само услугите на самия рутер. Работеща административна страница до мъртъв LAN е обичайният резултат от липсващото правило за препращане.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Погледнете целта за препращане на зоната, която носи тунела: accept е това, което е нужно на стълбицата, а reject обяснява всяко изтичане по-долу. Две съседни настройки дават същия симптом, затова ги изключете, докато сте тук. Безжичната изолация скрива кабелните хостове от безжичните клиенти, а рутер, който смята бездейните LAN хостове за офлайн, може да изхвърля отговорите дори след като препращането работи.

Защо разделеният тунел се нуждае от изтласкан префикс

Клиент, който изпраща целия трафик през тунела, вече държи LAN префикса чрез маршрута си по подразбиране, така че няма какво да се добави. Разделеният тунел е случаят, който изисква префиксът да бъде посочен изрично, защото нищо друго в конфигурацията не го споменава. Добавете директивата в конфигурацията на сървъра и презаредете услугата.

push "route 192.168.50.0 255.255.255.0"

Профили, съдържащи route-nopull игнорират изтласканите маршрути, затова същият префикс принадлежи във файла на клиента. Във всеки случай потвърдете, че записът е пристигнал, вместо да го предполагате, защото тихото заместване изглежда идентично на проблем със защитната стена.

ip route show | grep 192.168.50

Партньор сайт-към-сайт иска повече от изтласкване. Сървърът трябва да научи кои префикси стоят зад този партньор, което прави ред iroute във файла му client-config-dir, а собствената му таблица се нуждае от съответен маршрут в тунела.

Отговорът се нуждае от адрес, до който може да стигне

Препращането на заявката е само половината от обмена, защото LAN хостът трябва да отговори на адрес от пула на тунела. Малките рутери обикновено уреждат това чрез транслация на източника в зоната на тунела, така че отговорът е адресиран до рутера и не се нуждае от конфигурация другаде. Премахнете тази транслация и хостът ще се нуждае от собствен маршрут към пула, който получава безплатно, когато рутерът е шлюзът му по подразбиране. Хост с ръчно зададен адрес и друг шлюз отговаря през него и клиентът гледа как сесията се отваря и после засича.

tcpdump -ni tun0 host 192.168.50.20

Изпълнете това на рутера, докато клиентът повтаря заявката си, и четете дестинацията на отговора, а не самата заявка. Отговор, адресиран до пула, означава, че обратният път работи и повредата е по-навътре. Пълната липса на отговор означава, че хостът никога не е приел пакета, което ви връща към набора от правила.

Стълбица, която завършва на правилното място

Четири проверки локализират слоя и всяка е една команда, а не преценка. Изпълнете ги по ред и спрете при първия провал. Редът е по-важен от командите, защото успешната следваща стъпка скрива причината предишна да се е провалила.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Имената принадлежат в края на стълбицата, никога в началото. Споделена папка, която отговаря като 192.168.50.20, но не като nas.local, сочи към разпознаване на имена или към суфикс за търсене, а промените в защитната стена не могат да променят нито едното.

Запишете първата неуспешна стъпка, после дайте на портовете на услугите отделен проход, защото слушателят и разрешението на хоста са отделни изисквания. Споделянето на файлове, отдалеченият работен плот и потоците от камери се нуждаят от двете, а защитна стена на хоста, която вярва на LAN подмрежата, но не на пула на тунела, изхвърля клиента, докато ping още минава. Когато всички проверки минат, а приложението продължава да се проваля, повредата е над тунела: услуга, вързана към един интерфейс, или прокси, настроено на клиента.