Яку адресу джерела NGINX запише для клієнта VPN?

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

Вирішуйте за адресатом, а не за тим, хто користувач

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

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

Чому зовнішня кінцева точка створює другий публічний шлях

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

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

Читайте сокет, таблицю та формат журналу разом

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

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

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

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Виберіть потрібну точку входу і узгодьте DNS

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

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

Перевірте шлях, потім політику

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

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Далі перевірте доступ в обидва боки: передбачена названа точка входу працює для передбаченого клієнта, а несхвалений публічний шлях відхиляється, а не просто повільний. Звичайний сайт відлуння IP доводить щось про вихід шлюзу в інтернет і нічого про цей сайт на тому самому хості. Коли сторінка і WebSocket розходяться, порівняйте їхні URL, родини адрес і відповіді DNS, перш ніж торкатися конфігурації сервера.