IP-адреса виходу VPN не доводить тунель: що бачать сервери

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

Сервер бачить одну адресу на з'єднання

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

Усе після цієї адреси джерела — дані застосунку, і застосунок може довіряти їм лише настільки, наскільки він їх засвідчує.

Перевірте, як виглядає ваш вихід

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

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

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

Перелічити можна лише один із двох наборів виходів

Один випадок можна перевірити в момент запиту, а другий ні, що дає зовсім різні гарантії.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

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

Використовуйте адреси як вхід політики, а не як доказ

Вирішіть, для чого потрібне правило. Мережеве обмеження має залишатися вузьким, записувати спостережувану адресу з датою та причиною і давати законним користувачам шлях відновлення, коли їхній вихід змінюється. Контроль доступу потребує автентифікованого облікового запису або підписаного токена, бо лише вони пов'язують запит з особою. Оцінка ризику може використовувати адресу як єдиний ненадійний сигнал, приймаючи його хибні спрацювання та сліпі зони. Написати правило як продуктове рішення чесно; написати його як перевірку існування тунелю — ні.

Дзеркальний запит, відновлення справжньої адреси користувача за VPN, зазнає невдачі з тієї ж причини: одне з'єднання несе одну адресу, і зміна між сеансами узгоджується з кількома поясненнями. Ставтеся до попереднього значення як до історії, а не як до істини.