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

Останній крок: помістіть робочі правила в конфігурацію, яку читає перезапуск, і запишіть назву пристрою, який міст цього хоста справді використовує. Усе, набране вручну, зникає після перезавантаження, і та сама несправність повертається, не залишаючи нічого, що її пояснювало б.

Якщо після переписування лічильник усе ще не рухається, порівняйте діапазон джерела в правилі з адресою, яку клієнт справді отримав, бо сервер у режимі моста може видавати адреси з діапазону, якого ви не планували.