Перанакіраванне порта супраць доступу праз VPN: куды насамрэч ідзе пакет
Перанакіраванне порта перапісвае прызначэнне і спыняецца там; VPN спачатку заварочвае пакет. Паглядзіце, які ўзровень змяняе кожны і што гэта значыць для HTTPS.
Два дызайны, адна праграма HTTPS, і пакет у кожным ідзе іншым шляхам. Перанакіраванне порта змяняе месца дастаўкі пакета і не кранае астатняе. VPN спачатку нясе гэты пакет унутры іншага пакета, таму слухач праграмы бачыць іншую крыніцу і меншы максімальны карысны аб’ём. Шыфраванне, аб якім спрачаюцца, ёсць у абодвух выпадках, бо праграма ўсё яшчэ HTTPS; адрозніваецца тое, хто можа адкрыць злучэнне і што можа назіраць сетка паміж імі. Гэтае адрозненне вырашае большасць практычных пытанняў.
Правіла DNAT перапісвае прызначэнне і спыняецца там
На шлюзе Linux апублікаваць сэрвіс азначае правіла ў ланцужку PREROUTING табліцы nat або эквівалент у nftables. Правіла супастаўляе публічны адрас і порт, а затым перапісвае прызначэнне на прыватны адрас праграмы. Адрас крыніцы, порт крыніцы і карысны аб’ём застаюцца нязменнымі, а conntrack запісвае адпаведнасць, каб адказы перапісваліся назад пры выхадзе. Гэта традыцыйная мадэль трансляцыі адрасоў, апісаная ў RFC 3022.
sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
-j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443
Слухач праграмы ніколі не даведаецца, што злучэнне прыйшло праз трансляцыю. Ён бачыць сапраўдны адрас крыніцы кліента, што карысна для журналаў доступу і абмежаванняў хуткасці, і адказвае на прыватны адрас, бо conntrack абяртае адпаведнасць. Нішто на гэтым шляху не расшыфроўвае і не перашыфроўвае: TLS па-ранейшаму працуе паміж кліентам і ўласным сертыфікатам праграмы.
Правіла таксама вызначае рэжымы адмоваў, з якімі вы сутыкняцеся пазней. Калі шлюз перасылае, але хост праграмы не мае зваротнага шляху да кліента, адказы сыходзяць з няправільнай крыніцай і рукапоціск затынаецца. Калі другое правіла супадае першым, парадак вырашае вынік, і iptables -t nat -L -n -v паказвае лічыльнікі, якія даказваюць, якое правіла ўзяло пакет.
Тунель заварочвае пакет да таго, як слухач яго ўбачыць
VPN зусім не публікуе праграму. Кліент будуе знешні пакет, адрасаваны публічнаму адрасу шлюза, шыфруе ўнутры яго ўнутраны пакет, а шлюз расшыфроўвае і накіроўвае ўнутраны пакет да прыватнага прызначэння. У WireGuard знешні транспарт — UDP, звычайна на высокім порце; у OpenVPN праз TCP 443 знешні пакет выглядае як TLS для ўсяго, што назірае за шляхам.
Унутры тунеля ўнутраны пакет захоўвае прыватныя адрасы: адрас тунеля кліента, скажам 10.8.0.6, і праграма на 10.20.30.40. Таму слухач бачыць крыніцу з пула тунеля, і кожны кліент падзяляе гэты шлюз як наступны крок. Журналы доступу за VPN часта паказваюць менавіта шлюз, а не карыстальніка, калі шлюз не захоўвае першапачатковую крыніцу.
Заварочванне каштуе месца ў загалоўку, і гэта адзінае адрозненне на ўзроўні механізму з вынікам, які можна вымераць. Знешні загаловак IP плюс UDP плюс уласны загаловак WireGuard з’ядаюць MTU шляху, таму вялікія пакеты трэба фрагментаваць або ўнутраны стек TCP павінен абмежаваць свой MSS. Перадача, якая працуе па перанакіраваным шляху, можа застыць у тунелі, калі прамежкавы прыбор скідае ICMP, які паведаміў бы пра меншы MTU.
ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
Уздзеянне вызначаецца на ўваходзе, а не шыфрам
Абодва дызайны сканчаюцца на тым самым слухачы TLS, таму абодва атрымліваюць той самы сертыфікат, тыя самыя версіі пратакола і той самы ўваход у праграму. Змяняецца тое, каму дазволена пачаць рукапоціск. Пры публічным перанакіраванні любы хост, які дасягае 203.0.113.10:443, атрымлівае рукапоціск TCP і TLS ClientHello яшчэ да таго, як аўтарызацыя праграмы наогул правяраецца. Пры доступе толькі праз тунель слухач дасягальны толькі з адрасоў, якія шлюз накіроўвае ў тунель, а SYN чужога памірае на палітыцы шлюза.
Гэтае адрозненне пра дасягальнасць, а не пра канфідэнцыяльнасць. Перанакіраваны сэрвіс HTTPS не з’яўляецца адкрытым тэкстам, і VPN не адмяняе патрэбу ў аўтэнтыфікацыі праграмы: допуск у тунель адказвае, ці можа прылада слаць пакеты ў гэтую сетку, а файлавая праграма адказвае, ці можа карыстальнік чытаць дакумент. Змешванне гэтых двух — гэта як каманды атрымліваюць VPN, які дае ўсю лакальную сетку, і праграму з адным агульным паролем.
Даследуйце слухач і палітыку асобна, бо любое з іх можа быць шырэйшым, чым вы мяркуеце:
sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null
Калі ss паказвае, што слухач прывязаны да 0.0.0.0, праграма дасягальная адтуль, дзе дазваляюць маршрутызацыя і палітыка фаеруола, і перанакіраванне — толькі адзін са шляхоў унутр. Прывязаць да прыватнага адраса або абмежаваць дыяпазон крыніц у фаеруоле — гэта асобнае рашэнне ад выбару VPN, і менавіта яно звужае ўздзеянне.
Мерце шлях, а не этыкетку
Калі хтосьці сцвярджае, што перанакіраванне хутчэйшае, сумленнае параўнанне трымае ўсё астатняе нязменным: той самы кліент, тая самая сетка доступу, той самы файл, тая самая канфігурацыя TLS, той самы хост праграмы. Запусціце перадачу двойчы на кожны шлях і запішыце агульны час, колькасць збояў і рэагаванне, а не вынік непавязанага тэсту хуткасці.
curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40
Гэтыя лікі аддзяляюць усталяванне злучэння ад часу перадачы, што важна, бо два шляхі звычайна адрозніваюцца па часе кругавога шляху і MTU, а не па цане шыфравання. Праца TLS адбываецца на канцавых пунктах у абодвух дызайнах, а тунель дадае інкапсуляцыю, іншы маршрут і, магчыма, больш загружаны шлюз. Калі шлях тунеля даўжэйшы або яго шлюз загружаны, адрозненне належыць шляху, а не слову шыфраванне.
Выберыце палітыку ўваходу, якая сапраўды патрэбна сэрвісу, затым вырашыце, ці апраўдвае вымеранае адрозненне яе змену. Публічнае перанакіраванне падыходзіць для сэрвісу, прызначанага для адкрытага інтэрнэту, з абмежаваннямі крыніц, абноўленым TLS і маніторынгам перад ім. Доступ толькі праз тунель падыходзіць для ўнутранага інструмента, карыстальнікі якога ўжо зарэгістраваныя, пры ўмове, што маршрутызацыя шлюза і дазволы праграмы вузейшыя за ўсю лакальную сетку.
Перш чым назваць дызайн завершаным, пацвердзіце чатыры рэчы: да якога адраса прывязаны слухач, якое правіла або маршрут дапускае пакет, ці працуе зваротны шлях з сапраўднага адраса кліента і ці выжываюць вялікія аб’ёмы праз MTU. Для кожнага з іх ёсць каманда вышэй, і ні на адно з іх не адказвае слова «бяспечна» або графік прапускной здольнасці.