VPN підключено, але міжмережевий екран усе одно блокує: як зрозуміти, що саме

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

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

Відокремте шлях від політики

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

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

Прочитайте шлях за один прохід

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

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

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

Прочитайте політику на тому рівні, який відповідає

Коли шлях правильний, пройдіть політику від хоста назовні й стежте за тим єдиним рівнем, лічильники якого рухаються:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

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

Прочитайте рішення шлюзу, коли тунель закінчується там

На шлюзі «сайт-сайт» або віддаленого доступу VPN автентифікує користувача, а політика авторизує ресурс, і це окремі дозволи. Користувач, допущений у тунель, не отримує автоматично доступу до кожного внутрішнього хоста, і відмова часто приходить від правила пересилання, поки сам тунель у порядку. Те саме розділення є в IPsec, де політика безпеки, що вибирає трафік, відрізняється від фільтра, який його пропускає, і тому обидва описані як різні механізми в RFC 4301.

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

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

Змініть найвужчий рівень, потім перевірте

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

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

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Перш ніж закрити питання:

  • Маршрут до цілі виходить через інтерфейс тунелю, і адреса джерела збігається з тим, що очікує політика.
  • На порту щось слухає, і відмову або тайм-аут віднесено до названого правила, а не припущено.
  • Шлюз пересилає в обидва боки, і ціль бачить джерело, для якого написані ваші правила.
  • Жоден засіб контролю не було вимкнено заради проходження тесту, і зроблена зміна називає один діапазон джерела й один порт.

Схожі статті