Апублікуйце кліенцкі порт VPN з-за CGNAT: кантрольны спіс

Размясціце сэрвіс на ноўтбуку за NAT узроўню аператара, накіруйце гэты ноўтбук на VPS праз VPN, і ніхто звонку не зможа да яго дабрацца. Вы дадаяце правіла NAT прызначэння на VPS і атрымліваеце нешта горшае за цішыню: злучэнні адкрываюцца, а потым заміраюць. Адказ не знікае, ён сыходзіць праз уласны маршрут кліента па змаўчанні, а гэта значыць, што сервер ніколі яго не бачыць. Прайдзіце гэтыя пяць праверак па парадку і спыніцеся на першай, якая не вытрымае.

Пераканайцеся, што сервер увогуле будзе перасылаць

Адзначце гэты пункт, перш чым пісаць хоць адзін пераклад. Правіла DNAT для пакета, які ядро адмаўляецца перасылаць, прымаецца разборшчыкам правілаў і потым адкідаецца шляхам перасылкі, што дае тайм-аўт, падобны на праблему з файрволам.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Задаць гэта ў працуючым ядры не тое самае, што задаць праз перазагрузку. Запішыце net.ipv4.ip_forward=1 у файл у /etc/sysctl.d/, выканайце sysctl --system, а затым прачытайце значэнне назад замест таго, каб давяраць, што файл быў успрыняты. Кантэйнер, які кіруе сваёй прасторай імёнаў сеткі, мае патрэбу ў тым жа значэнні ўнутры гэтай прасторы, а не толькі на хасце.

Калі чытанне ўсё яшчэ дае нуль, спыніцеся тут. Нішто далей не будзе працаваць.

Замацуйце адрас тунеля, перш чым на яго спашлецца любое правіла

Пул выдае адрасы ў парадку злучэнняў, таму правіла, напісанае для сённяшняй арэнды, можа ціха паказваць на іншага кліента на наступным тыдні. Прывяжыце адрас да ідэнтычнасці сертыфіката, а не да парадку прыходу.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Гэтая пара — гэта кліенцкі канец і канец партнёра тунеля пункт-пункт, прычым сервер прывязаны да агульнага імя сертыфіката. У тапалогіі падсеткі другое значэнне чытаецца як маска сеткі, таму пішыце форму, якая адпавядае тапалогіі ў выкарыстанні. Затым перападключыце кліента і прачытайце адрас на самім кліенце, бо погляд сервера на пул не з'яўляецца доказам таго, што наладзіў кліент.

Калі адрас змяняецца пасля перападключэння, спыніцеся. Правіла NAT, якое ідзе за рухомай мэтай, будзе збоіць праз інтэрвалы і нічому вас не навучыць.

Перакладайце ў абодвух кірунках

Пераклад прызначэння адпраўляе ўваходны пакет кліенту. Менавіта пераклад крыніцы прымушае кліента адказваць серверу, а не першапачатковаму адпраўніку, і гэта тое правіла, якое людзі прапускаюць.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

Без другога правіла кліент адказвае праз узыходны канал свайго Інтэрнэт-правайдэра, таму аддалены партнёр бачыць адрас крыніцы, з якім ён ніколі не размаўляў, пакуль сервер не трымае ніякага запісу адсочвання для адказу. Знешні назіральнік бачыць рукапоціск, які завяршаецца напалову, і гэта менавіта той сімптом, які гоніць людзей шукаць памылку ў файрволе, якой няма.

Прачытайце абодва правілы назад з iptables -t nat -S і пераканайцеся, што імя інтэрфейса — тое, якое нясе публічны адрас. На хасце, які ўжо фільтруе праз nftables, запішыце пераклад у ланцуг NAT nftables адпаведнага сямейства адрасоў замест змешвання інструментаў.

Дайце табліцы фільтраў прапускаць

Табліцы NAT перапісваюць загалоўкі; яны не даюць дазволу. Пры палітыцы DROP па змаўчанні перасылаемы паток патрабуе ўласнага прыняцця, плюс зваротны кірунак, які большасць палітык ужо пакрывае правілам established,related.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Праверце палітыку ланцуга FORWARD, перш чым нешта дадаваць, бо парадак ранняга DROP вырашае, ці будзе ваша правіла ўвогуле разгледжана. На хасце, чыя фільтрацыя жыве ў nftables, дадайце эквівалентнае правіла ў хук forward табліцы inet і пераканайцеся, што базавы ланцуг сапраўды бачыць перасылаемы трафік, а не толькі лакальны ўвод. Калі лічыльнік пакетаў на новым правіле застаецца на нулі, пакуль лічыльнікі NAT растуць, пакет адкідаецца да вашага правіла. Гэта сігнал прачытаць парадак ланцугоў, а не дадаць другую копію таго ж правіла.

Дакажыце гэта з знешняй сеткі

Тэстуйце з непавязанай сеткі. Спроба з іншай машыны ў той жа лакальнай сетцы можа прайсці праз падтрымку hairpin NAT і ніколі не выпрабаваць шлях, які выкарыстоўвае аддалены кліент, таму зялёны вынік там даказвае не тое.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Запускайце захоп на серверы і на кліенце адначасова. Захоп на серверы паказвае, ці пакет пасля перакладу выходзіць да тунеля; захоп на кліенце паказвае, ці запыт прыходзіць і куды адрасаваны адказ. Запіс перакладу ў conntrack -L даказвае, што правіла супала, а яго адсутнасць даказвае, што пакет ніколі не дасягнуў ланцуга NAT.

Сканеры партоў — слабы доказ. Яны паведамляюць парт як закрыты, пакуль праграма не прывязана і не слухае, таму выкарыстоўвайце сапраўднае злучэнне з сапраўдным сэрвісам. Калі гэта нарэшце спрацуе, трымайце экспазіцыю на адным гэтым порце: перасылка SSH або адмін-панэлі таму, што першае правіла здалося няёмкім, — гэта значна большае рашэнне, чым публікацыя сэрвісу.