Пренасочване на порт срещу 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. За всяко от тях има команда по-горе и на нито едно не отговаря думата сигурно или графика за честотна лента.

Подобни статии