Мостови клиенти на 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.

Докажете го от край до край, после го направете постоянно

Вдигнете един клиент и пингнете нещо в LAN на сървъра; този път упражнява препращането без никаква транслация. След това поискайте нещо публично, за да се използва правилото masquerade, и прочетете брояча отново: той трябва да мръдне за този тест, а не за предишния. Снимка, направена на устройството на тунела, показва едновременно къде се появява кадърът и какъв адрес носи.

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

Ако броячът все още не мърда след пренаписването, сравнете диапазона на източника в правилото с адреса, който клиентът действително е получил, защото сървър зад мост може да раздава адреси от диапазон, който не сте предвидили.