Препраќање порт наспроти 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 што го дава целиот LAN и апликација со една заедничка лозинка.

Прегледајте ги слушателот и политиката одделно, бидејќи секое од нив може да биде пошироко отколку што претпоставувате:

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 и надзор пред неа. Пристапот само преку тунел одговара на внатрешна алатка чии корисници се веќе запишани, под услов рутирањето на порталот и дозволите на апликацијата да се двете потесни од целиот LAN.

Пред да го прогласите дизајнот за завршен, потврдете четири работи: на која адреса е врзан слушателот, кое правило или маршрута го пушта пакетот внатре, дали повратниот пат работи од вистинската адреса на клиентот и дали големите корисни товари го преживуваат MTU. За секоја од нив горе има команда, и ниту една не е одговорена со зборот безбедно или со графикон за пропусен опсег.

Поврзани статии