Клиенты OpenVPN в режиме моста без интернета? Проверьте правило NAT

Сервер в режиме моста запущен, правило masquerade на месте, а браузер на клиенте всё равно крутится. Всё выглядит так, будто должно работать, поэтому первый час уходит на проверку туннеля и учётных данных. Затем вы читаете счётчик правила NAT и видите ноль, который не сдвинулся. Правило, которое ни разу не посчитало пакет, ни разу и не совпало с ним, а на сервере в режиме моста причина структурная: трафик клиента выходит через виртуальное устройство tap, тогда как правило называет физическую карту, скопированную из старого руководства.

Доказательство — счётчик, а не запись в таблице

Существующие правила и совпадающие правила — разные вещи, и разделяет их счётчик. Выведите таблицу NAT с подробными счётчиками и прочитайте числа рядом с каждым правилом, прежде чем что-то менять. Счётчик, замерший на нуле при идущем трафике, означает, что правило было пропущено, какими бы разумными ни казались его адреса. Счётчик, который растёт, пока соединение всё ещё не работает, отправляет вас в другое место: к пересылке, обратному пути или дальнему концу.

iptables -t nat -L POSTROUTING -v -n

Сначала прочитайте счётчик рядом с совпадением интерфейса. Если диапазон источника верен, а сторона выхода неверна, исправление — одно слово в правиле, а не полностью новое правило.

Найдите имя, которое ядро действительно записывает

Определите имя туннельного устройства до того, как писать правило, по списку интерфейсов, а не по памяти. В конфигурации OpenVPN в режиме моста устройство обычно представляет собой интерфейс tap, созданный сервером, и его имя является частью вашей локальной конфигурации, а не универсальной константой. Убедитесь, что оно существует, пока туннель поднят, потому что устройство, появляющееся только после подключения клиента, заставит более раннюю проверку выглядеть как проблема с правилом.

ip -brief link

Запишите имя. Каждая последующая команда в этой диагностике ссылается на него, и опечатка здесь даёт ровно такой же нулевой счётчик, как и исходная ошибка.

Перепишите правило под туннельное устройство

Направьте правило на туннельное устройство и оставьте диапазон клиентов условием совпадения, чтобы оно охватывало туннельный трафик и не трогало собственные соединения хоста. Подставьте свой диапазон и имя устройства, потому что оба ниже — примеры, и ни один не переносим между установками.

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

Затем проверьте два других условия, которые скрывает тот же симптом. Проверьте, включена ли пересылка, и если нет, включите её в конфигурации самого дистрибутива, а не через echo, который исчезает после перезагрузки. Прочитайте и счётчики цепочки forward: если она отбрасывает туннельный трафик, разрешите именно этот интерфейс и не трогайте политику цепочки.

Чтение цепочки forward со счётчиками занимает одну команду и отсекает половину оставшихся возможностей, прежде чем вы коснётесь другого правила.

Почему физическая карта никогда не совпадает

Мост — это программный коммутатор, собранный из устройства tap и одного физического интерфейса. Кадр клиента входит в этот коммутатор и выходит к физической сети как член моста, а не как пакет на карте. Поэтому ядро приписывает пакет мосту и его порту, и поэтому карта, о которой вы думали, никогда не появляется в совпадении. С физическим интерфейсом ничего не сломано; он просто не является тем устройством, которому ядро приписывает этот пакет.

Следующая проблема, с которой сталкиваются люди, происходит из той же структуры: фильтрация кадров на мосту — отдельный механизм от фильтрации IP. Если требуется ограничение на уровне кадров, оно относится к фильтрации моста, а не к правилу таблицы IP.

Докажите это от начала до конца, затем закрепите

Поднимите одного клиента и пропингуйте что-нибудь в локальной сети сервера; этот путь задействует пересылку без какого-либо преобразования. После этого запросите что-нибудь публичное, чтобы правило masquerade пришлось использовать, и прочитайте счётчик ещё раз: он должен сдвинуться для этой проверки, а не для предыдущей. Захват, сделанный на туннельном устройстве, показывает и где появляется кадр, и какой адрес он несёт.

Последний шаг: поместите работающие правила в конфигурацию, которую читает перезапуск, и запишите имя устройства, которое мост этого хоста действительно использует. Всё, набранное вручную, исчезает после перезагрузки, и та же неисправность возвращается, не оставляя ничего, что её объясняло бы.

Если после переписывания счётчик всё равно не двигается, сравните диапазон источника в правиле с адресом, который клиент действительно получил, потому что сервер в режиме моста может выдавать адреса из диапазона, который вы не планировали.