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 клиенттері үшін туннель адресіне шешілетін ат беріңіз және тыңдаушы сокетте саясатты қолданыңыз. Ішкі ат үшін 10.24.0.1 қайтаратын бөлінген DNS жауабы ат шешу бөлшегінің киіміндегі маршруттау шешімі. Егер сайт ашық та болуы керек болса, екі ат немесе екі порт сақтаңыз және қайсысы сұрауға қызмет еткенін журнал айтсын.

Рұқсат ету ережелері сол логиканы ұстанады. Туннель пулына рұқсат беру ашық сұрауға құқық бермейді және интернет арқылы келген қосылымда ішкі адресті толтырмайды. Екі кіру нүктесін бір ат астында араластыру жазылған бастауышты жобалау таңдауының орнына клиент маршруттауының жанама әсеріне айналдырады.

Жолды, содан кейін саясатты тексеріңіз

Жолды шлюзде алынған түсіріліммен және өзіңіз бақылайтын сұраумен растаңыз. Туннель құрылғысындағы түсірілім және ашық интерфейстегі біреуі қайсысы байттарды тасымалдағанын көрсетеді, ал пакеттердің реті олардың арасында аударма болғанын айтады.

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

Содан кейін қатынауды екі бағытта тексеріңіз: көзделген атаулы кіру көзделген клиент үшін жұмыс істейді және мақұлданбаған ашық жол жай ғана баяу болудың орнына қабылданбайды. Жалпы IP-жаңғырық сайты шлюздің интернетке шығуы туралы бірдеңе дәлелдейді және сол хосттағы осы сайт туралы ештеңе дәлелдемейді. Бет пен WebSocket келіспесе, сервер конфигурациясына тиер алдында олардың URL-ларын, адрес топтарын және DNS жауаптарын салыстырыңыз.

Қатысты мақалалар