Той самы IP-адрас сервера, два шляхі: маркіраванне знешняга патоку OpenVPN

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

Пачніце з двух патокаў, якія трэба падзяліць

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

У гэтым разборы прадугледзім кліента на 10.90.0.10 праз tun1, публічны адрас сервера 198.51.100.25 і недакранутую галоўную табліцу, маршрут па змаўчанні якой паказвае на звычайны аплінк. Серверны бок таксама павінен прымаць вэб-службу на ўнутраным шляху і вяртаць трафік да тунельнай крыніцы; адпраўка пакета на публічны адрас не адмяняе ні слухача, ні палітыку міжсеткавага экрана сервера.

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

Пазначце сокет, які нясе канверт

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

mark 42
route-noexec
disable-dco

Дзесятковае 42 — гэта шаснаццатковае 0x2a, і менавіта шаснаццатковую форму будуць супастаўляць правілы маршрутызацыі. Даведка па link-options апісвае mark як тое, што прымяняецца да зашыфраваных зыходных пакетаў у Linux, гэта значыць роўна да таго сокета, чыім шляхам трэба кіраваць. Выключэнне разгрузкі канала даных утрымлівае гэты прыклад на шляху прасторы карыстальніка, дзе паводзіны меткі — тыя самыя апісаныя.

route-noexec падаўляе аўтаматычнае даданне і выдаленне маршрутаў з боку OpenVPN. Замест гэтага ён нічога не ўсталёўвае, таму з гэтага моманту ўладальнік маршрутаў павінен падтрымліваць кожны маршрут, патрэбны тунелю. Калі прыватны адрасат знікае пасля змены, гэта адсутная палітыка замены, а не дэфект меткі.

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

Адпраўце ўсё астатняе ў табліцу тунеля

Як толькі інтэрфейс тунеля існуе і трымае свой адрас, палітыка выглядае так:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

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

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

Няхай зваротны шлях бачыць тую самую метку

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

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

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

Давядзіце гэта двума пошукамі маршруту

Параўнайце, што вырашае ядро для двух кантэкстаў, і чытайце палі dev і src, а не код выхаду:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

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

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