Які адрас крыніцы запіша 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, перш чым кранаць канфігурацыю сервера.