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

Сокет або прив'язаний, або ні

Служба, яка повідомляє про активність, усе ще може бути прив'язана до адреси або транспорту, яких ви не передбачали. Запитайте сам сокет: ss -lunp перелічує UDP-слухачів, а ss -ltnp перелічує TCP, і стовпець, який варто читати, це локальна адреса, а не стан.

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

ss -lunp | grep 1194
ss -ltnp | grep 1194

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

Перехопіть зовнішній пакет, а не тунель

Фільтруйте на фізичному інтерфейсі та справжньому порту, підставивши свій інтерфейс: tcpdump -ni eth0 udp port 1194. Вихідні пакети, на які нічого не повертається, вказують на те, що вище: фільтрація провайдера, пристрій NAT або віддалена адреса, яка не та, що ви думаєте. Тиша в обидва боки вказує на маршрутизацію клієнта або локальний міжмережевий екран. Відповіді, що приходять без просування тунелю, вказують на канал керування, тобто на невідповідність ключа або шифру, а не на фільтрацію.

Перехопіть обидва напрямки і тримайте файл коротким. Довге перехоплення ховає цікаві три секунди, і відповідь майже завжди лежить у першому обміні.

Спочатку лічильники, трасування лише коли вони брешуть

Почніть із лічильників, бо вони нічого не коштують. Або nft list ruleset, або iptables -L -n -v відповідає на єдине важливе тут питання: чи правило збіглося? Порядок вирішує результат, бо перший збіг перемагає, тому широкий DROP перед пізнішим ACCEPT залишає той ACCEPT мертвим і тому додавання правила так рідко щось виправляє.

Належність також спотикає людей. Ядро приписує локально створені пакети процесу, який відкрив сокет, а OpenVPN зазвичай працює як root, тому правило, прив'язане до звичайного ID користувача, ніколи не бачить трафік самого тунелю. Перевірте UID власника, перш ніж вирішити, що правило хибне.

Лише коли лічильники залишаються неоднозначними, журнал вартий шуму, і то лише для вузького зрізу: правило iptables, яке обмежує швидкість і додає префікс до своїх рядків, або правило nftables з meta nftrace set 1 при працюючому nft monitor trace. Трасування називає ланцюг і правило, яке прийняло або відкинуло пакет. Потім приберіть обидва і тримайте журналювання корисного навантаження осторонь.

Перевірте й транспорт. Служба міжмережевого екрана, обмежена TCP, нічого не каже про UDP-слухача на цьому номері, тому правильно прочитане правило все одно може відкидати кожен пакет.

Маршрутизація і зворотний шлях

Прийнятий пакет, який усе ж зникає, потребує перевірки шляху до призначення. ip route get повідомляє маршрут, вибраний для однієї адреси, а фільтрація зворотного шляху може відкинути відповідь, що надходить через інтерфейс, який основна таблиця ніколи не вибрала б. Симптом виглядає точно як відкидання міжмережевим екраном, тому ця перевірка йде перед черговим правилом NAT.

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

Що має сказати запис

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

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

Схожі статті