Доступ да 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 яшчэ праходзіць. Калі ўсе праверкі пройдзены, а праграма ўсё яшчэ збоіць, няспраўнасць над тунэлем: служба, прывязаная да аднаго інтэрфейсу, або проксі, наладжаны на кліенце.