Немає доступу до 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 ще проходить. Коли всі перевірки пройдено, а застосунок усе одно не працює, несправність над тунелем: служба, прив'язана до одного інтерфейсу, або проксі, налаштований на клієнті.

Схожі статті