Кой адрес на източника ще запише NGINX за VPN клиент?

Решете какво вижда NGINX до OpenVPN на един хост: вътрешен адрес на тунела, публичен изходящ адрес или препратен партньор, според поетия път.

В инсталация на NGINX и OpenVPN на един и същ хост се появяват три клиентски адреса, по един за всеки път, който заявката може да поеме. Браузър, който стига до адреса на тунела, браузър, който стига до публичния адрес, и програма, която излиза по интернет пътя на шлюза, изглеждат различно на слушащия сокет. Решете кой път наблюдавате, преди да тълкувате реда в журнала. Решението зависи от дестинацията, която клиентът е използвал, от изключението, което държи за външната крайна точка на VPN, и от това дали нещо превежда пакета по пътя.

Решавайте по дестинация, а не по това кой е потребителят

Започнете с адреса, на който е изпратена заявката, защото този адрес избира пътя. Заявка към адреса на тунела на хоста пристига на интерфейса на тунела с вътрешния адрес на клиента като източник. Заявка към публичния адрес на хоста обикновено пристига на интерфейса, обърнат към интернет, с публичния адрес на клиента, дори когато същият лаптоп има установен тунел в този момент. Следователно принадлежността към пула на VPN е свойство на пътя на пакета, а не свойство, което следва потребителя.

Path the request tookSource the site normally records
Client reaches the site at its tunnel address, 10.24.0.1Client inner address, 10.24.0.20
Client reaches another internet site through the gatewayGateway public egress address, 192.0.2.44
Client reaches the gateway's public address through the endpoint exceptionClient's own public access address

Точно този трети ред си струва да се провери първо, когато в журнала се появи 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 отговорите, преди да пипате конфигурацията на сървъра.

Подобни статии