VPN клиентите стигат до сървъра, но не до LAN мрежата: кое решение?

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

Първо установете коя посока е счупена

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

Тествайте двете машини, преди да промените която и да е. Попитайте сървъра по кой път таблицата му би стигнала до клиент; попитайте хоста в LAN мрежата как би стигнал до същия адрес. Първото търсене обикновено сочи тунела, а второто рутера на LAN мрежата, и тази разлика е повредата в един ред. Две търсения са по-евтини от одит на защитната стена и определят посоката на проблема.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Ако хостът в LAN мрежата вече сочи към VPN сървъра, проблемът е правило на защитната стена или ограничение на MTU, а не липсващ обратен път. Не добавяйте маршрут, за да поправите филтър.

Първи въпрос: можете ли да редактирате рутера на отдалечената LAN мрежа?

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

Тихо се проваля в деня, когато някой смени пула. Запишете стойността веднъж и третирайте промяна на което и да е от трите места като промяна на всичките три.

NAS или Layer 3 комутатор, който хоства услугата, се нуждае от същия маршрут, освен ако не изпраща всичко през рутер, който го има. Проверете устройството, което завършва подмрежата, не само това към интернет. Малките мрежи често имат три устройства с мнение за маршрутизирането.

Втори въпрос: може ли LAN мрежата да спре да вижда адресите на клиентите?

Когато рутерът принадлежи на някой друг, преводът на VPN сървъра не изисква съдействие. Хостът в LAN мрежата вижда адреса на LAN мрежата на сървъра, отговаря му, а сървърът превежда обратно. Затова устройствата и ролите за отдалечен достъп, базирани на NAT, се държат така.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Цената е приписването: адресите по клиент изчезват от записите на LAN мрежата. Всеки списък с разрешени на хоста в LAN мрежата тогава трябва да посочи сървъра вместо пула.

Изберете превода, когато съдействието не е налично, не когато е само неудобно. Той скрива клиента от всяко бъдещо разследване, включително тези, в които трябва да знаете кой лаптоп е отворил връзка. Може също да развали протоколи, които вграждат адреси в полезния товар, защото преводът живее в заглавката. Нито една възможност не е по-напреднала; те отговарят на различни въпроси за собствеността.

Трети въпрос: сървърът сам клиент ли е на друг тунел?

Представете си другата топология: VPN сървърът също набира търговски доставчик, така че има два тунела и два набора адреси. Трафикът, който препраща за собствените си клиенти, излиза през доставчика, а той няма да насочи отговорите обратно към адресите на пула. Затова отговорите изчезват, макар и двата тунела да са здрави.

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

След това проверете двете посоки и двата размера

След промяната направете ping от клиента към хост в LAN мрежата и после от хоста в LAN мрежата към клиента. Втората посока е тази, която хората пропускат, и тя разкрива непълно правило за превод. Запишете двата резултата с времева марка, за да е сравнимо едно по-късно връщане на дефекта.

След това прехвърлете истински данни, защото малък ping, който минава, докато голям трансфер засича, е симптом на MTU. Тази повреда се появява веднага след като се поздравите за поправения маршрут.

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