Коју изворну адресу ће 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 за унутрашње име је одлука о рутирању прерушена у детаљ разрешавања имена. Ако сајт мора да буде и јаван, задржите два имена или два порта и пустите дневник да каже који је послужио захтев.

Правила дозволе следе исту логику. Дозвола VPN базену не овлашћује јавни захтев и неће попунити унутрашњу адресу на вези која је дошла преко интернета. Мешање обе улазне тачке под једним именом претвара забележени извор у нуспојаву рутирања клијента уместо пројектне одлуке.

Проверите пут, затим политику

Потврдите пут снимком на пролазу и захтевом који контролишете. Снимак на уређају тунела и један на јавном интерфејсу показују који је носио бајтове, а редослед пакета вам каже да ли је између њих дошло до превода.

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

Затим проверите приступ у оба смера: предвиђена именована улазна тачка ради за предвиђеног клијента, а неодобрени јавни пут се одбија уместо да буде само спор. Општи сајт са одјеком IP-а доказује нешто о интернет излазу пролаза и ништа о овом сајту на истом домаћину. Када се страница и WebSocket не слажу, упоредите њихове URL-ове, фамилије адреса и DNS одговоре пре него што додирнете конфигурацију сервера.

Повезани чланци