Як кліент OpenVPN за NAT становіцца выхадам у інтэрнэт

Тры Linux-хості, адна схема: публічна даступны цэнтр OpenVPN, спажывецкі ноўтбук і машына-выхад за звычайным хатнім маршрутызатарам, які нічога не перасылае ўнутр. Выхад сам падключаецца да цэнтра. Затым інтэрнэт-трафік спажыўца ўваходзіць у тунель на ноўтбуку і выходзіць праз уласны ўзыходзячы канал выхаду. Усё дзіўнае ў гэтай схеме вынікае з адной дэталі: злучэнне ініцыяваў выхад, таму шлях унутр ужо існуе і перасылка порта не патрэбна, каб яго стварыць.

Далей разглядаецца шлях пакета, а не парадак налады, бо налада мае сэнс толькі тады, калі вы ведаеце, які кампанент прымае якое рашэнне. Кожны ўзровень прымае роўна адно рашэнне, а памылкі збіраюцца там, дзе два ўзроўні лічаць адным.

Дзве транспартныя сесіі, адзін унутраны шлях

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

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

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

Што iroute насамрэч усталёўвае ўнутры сервера

Цэнтр — адзіная прылада, якая вырашае, якому партнёру належыць якое прызначэнне, і робіць гэта ў сваёй табліцы маршрутызацыі прасторы карыстальніка, а не ў табліцы ядра. Запіс client-config-dir для выхаду з іменем exit-node можа заявіць там стандартны прэфікс:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

Гэты радок кажа працэсу сервера: "унутраныя пакеты з любым прызначэннем належаць гэтаму кліенту". Ён не дадае стандартны маршрут у аперацыйную сістэму цэнтра і не робіць цэнтр інтэрнэт-шлюзам. Даведнік OpenVPN 2.6 трымае ўнутранае маршрутызаванне канкрэтнага кліента і маршрутызаванне ядра як асобныя механізмы, і менавіта гэтае раздзяленне тлумачыць, чаму схема працуе без змены стандартнага маршруту цэнтра.

Спажыўцу патрэбна люстраная інструкцыя, дастаўленая як push, каб яго ўласны трафік уваходзіў у тунель, а не выходзіў праз лакальны шлюз. Пры тапалогіі падсеткі пул — гэта далучаны маршрут на прыладзе tun выхаду, таму зваротны кірунак не патрабуе дадатковага push; выхад не павінен атрымаць прыведзенае ніжэй перанакіраванне, якое адаслала б яго ўласны ўзыходзячы трафік назад у тунель, які ён спрабуе выкарыстаць. Дасылайце яго толькі спажыўцу і чытайце ўжытыя маршруты на кліенце, а не спадзявайцеся, што файл CCD быў выбраны.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

Перасылку выконвае ядро выхаду

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

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

Зваротны шлях забяспечвае трансляцыя крыніцы

Інтэрнэт-хост не мае маршруту да адраса 10.90.0.x, таму адказы адкідаліся б яшчэ да таго, як дасягнулі б выхаду. Перазапіс крыніцы, калі пакет пакідае ўзыходзячы канал, вырашае гэта, а адсочванне злучэнняў абяртае перазапіс на зваротным шляху.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

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

Дзе цэнтр можа і не можа прымяніць правілы

З client-to-client і традыцыйным шляхам даных у прасторы карыстальніка цэнтр перадае ўнутраныя пакеты паміж партнёрамі ўнутры працэсу сервера. Яны ніколі не праходзяць праз ланцуг FORWARD ядра цэнтра, таму правіла ў ядры там не можа абмежаваць транзіт паміж партнёрамі, як бы старанна яно ні было напісана. Прымяненне павінна жыць ва ўласнай палітыцы сервера: каму дазволена падключацца, які файл CCD яны атрымліваюць і ці даецца наогул стандартнае валоданне выхадам.

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

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

Бяспечнае збоі, калі выхад знікае

Адключыце выхад, і ўнутранае стандартнае валоданне знікае разам з яго сесіяй. Чаго не павінна здарыцца — гэта каб цэнтр ціха стаў заменным выхадам: ніякага стандартнага маршруту з пула VPN ва ўзыходзячы канал цэнтра і ніякага шырокага правіла маскіравання на цэнтры, якое ахвотна пераслала б той самы трафік. Праверце гэты збой наўмысна, а затым праверце аднаўленне свежым патокам, а не старонкай, якая ўжо была адкрыта.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Калі трафік спажыўца ўсё яшчэ дасягае інтэрнэту пасля знікнення выхаду, яго нясе нешта іншае, і мяжы, якую вы мелі на ўвазе, не існуе. Разглядайце DNS і IPv6 як асобныя рашэнні: маршрут IPv4 плюс маскіраванне нічога не кажуць пра трафік AAAA, а рэзалвер, прасунуты цэнтрам, будзе адказваць адтуль, адкуль запыт сапраўды выходзіць.