Која изворна адреса ќе ја запише 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 пред да ја допрете конфигурацијата на серверот.

Поврзани статии