Porttovábbítás kontra VPN-hozzáférés: hová megy valójában a csomag

A porttovábbítás átírja a célt, és ott megáll; a VPN előbb beburkolja a csomagot. Nézze meg, melyik melyik réteget változtatja, és ez mit jelent a HTTPS számára.

Két terv, egy HTTPS-alkalmazás, és a csomag mindkettőben más útvonalat jár be. A porttovábbítás megváltoztatja, hova kerül a csomag, és a többit érintetlenül hagyja. A VPN előbb egy másik csomagba csomagolja, ezért az alkalmazás figyelője más forrást és kisebb maximális hasznos terhet lát. A titkosítás, amiről vitatkoznak, mindkét esetben jelen van, mert az alkalmazás továbbra is HTTPS; ami különbözik, az az, ki nyithat kapcsolatot, és mit figyelhet meg a köztes hálózat. Ez a különbség dönti el a gyakorlati kérdések többségét.

A DNAT-szabály átírja a célt, és ott megáll

Egy Linux-átjárón egy szolgáltatás közzététele egy szabályt jelent a nat tábla PREROUTING láncában, vagy ennek megfelelőjét nftablesben. A szabály a nyilvános címre és portra illeszkedik, majd átírja a célt az alkalmazás privát címére. A forráscím, a forrásport és a hasznos teher érintetlen marad, a conntrack pedig rögzíti a leképezést, hogy a válaszok kimenetkor visszaíródjanak. A viselkedés az RFC 3022-ben leírt hagyományos címfordítási modell.

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

Az alkalmazás figyelője soha nem tudja meg, hogy a kapcsolat fordítás révén érkezett. Látja az ügyfél valódi forráscímét, ami hasznos a hozzáférési naplókhoz és a sebességkorlátokhoz, és a privát címre válaszol, mert a conntrack megfordítja a leképezést. Ezen az útvonalon semmi nem fejt vissza vagy titkosít újra: a TLS továbbra is az ügyfél és az alkalmazás saját tanúsítványa között fut.

A szabály a később találkozó hiba­módokat is meghatározza. Ha az átjáró továbbít, de az alkalmazás gazdagépének nincs visszaútja az ügyfélhez, a válaszok rossz forrással mennek ki, és a kézfogás elakad. Ha egy második szabály illeszkedik előbb, a sorrend dönti el az eredményt, és iptables -t nat -L -n -v megmutatja a számlálókat, amelyek bizonyítják, melyik szabály vette el a csomagot.

Az alagút beburkolja a csomagot, mielőtt a figyelő látná

A VPN egyáltalán nem teszi közzé az alkalmazást. Az ügyfél egy külső csomagot épít az átjáró nyilvános címére címezve, titkosítja benne a belső csomagot, az átjáró pedig visszafejti és a belső csomagot a privát célra irányítja. WireGuardnál a külső átvitel UDP, általában magas porton; OpenVPN esetén TCP 443 felett a külső csomag TLS-nek látszik minden számára, ami az útvonalat figyeli.

Az alagúton belül a belső csomag megtartja a privát címeket: az ügyfél alagútcíme, mondjuk 10.8.0.6, és az alkalmazás a 10.20.30.40 címen. A figyelő ezért az alagútpoolból lát forrást, és minden ügyfél ezt az átjárót osztja meg következő ugrásként. A VPN mögötti hozzáférési naplók éppen ezért mutatják gyakran az átjárót a felhasználó helyett, hacsak az átjáró nem őrzi meg az eredeti forrást.

A beburkolás fejléc-területbe kerül, és ez az egyetlen mérhető következménnyel járó mechanizmus szintű különbség. Egy külső IP-fejléc plusz UDP plusz a WireGuard saját fejléce az útvonal MTU-jából eszik, ezért a nagy csomagokat fel kell darabolni, vagy a belső TCP-veremnek korlátoznia kell az MSS-ét. Egy átvitel, amely a továbbított útvonalon működik, az alagúton elakadhat, amikor egy köztes eszköz eldobja azt az ICMP-t, amely a kisebb MTU-t jelezte volna.

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

A kitettséget a belépés dönti el, nem a titkosítás

Mindkét terv ugyanahhoz a TLS-figyelőhöz érkezik, ezért mindkettő ugyanazt a tanúsítványt, ugyanazokat a protokollverziókat és ugyanazt az alkalmazásbejelentkezést örökli. Az változik, ki kezdhet kézfogást. Nyilvános továbbításnál minden gazdagép, amely eléri a 203.0.113.10:443 címet, TCP-kézfogást és TLS ClientHello-t kap, mielőtt az alkalmazás engedélyezését egyáltalán megnéznék. Csak alagúton keresztüli hozzáférésnél a figyelő csak azokról a címekről érhető el, amelyeket az átjáró az alagútba irányít, és az idegen SYN-je az átjáró házirendjén hal meg.

Ez a különbség az elérhetőségről szól, nem a bizalmasságról. Egy továbbított HTTPS-szolgáltatás nem sima szöveg, és a VPN nem szünteti meg az alkalmazás-hitelesítés szükségét: az alagútba való beengedés arra válaszol, küldhet-e egy eszköz csomagokat ebbe a hálózatba, míg a fájlalkalmazás arra, olvashat-e egy felhasználó dokumentumot. A kettő összekeverése vezet ahhoz, hogy a csapatok olyan VPN-hez jutnak, amely az egész LAN-t átadja, és egyetlen közös jelszavú alkalmazáshoz.

Vizsgálja meg a figyelőt és a házirendet külön, mert bármelyik szélesebb lehet, mint feltételezi:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Ha ss azt mutatja, hogy a figyelő a 0.0.0.0 címhez van kötve, az alkalmazás onnan érhető el, ahol az útválasztás és a tűzfal házirendje engedi, és a továbbítás csak az egyik bejárat. A privát címhez kötés vagy a forrástartomány tűzfalbeli szűkítése a VPN választásától külön döntés, és ez az a döntés, amely valóban szűkíti a kitettséget.

Az útvonalat mérje, ne a címkét

Amikor valaki azt állítja, hogy a továbbítás gyorsabb, az őszinte összehasonlítás minden mást állandóan tart: ugyanaz az ügyfél, ugyanaz a hozzáférési hálózat, ugyanaz a fájl, ugyanaz a TLS-konfiguráció, ugyanaz az alkalmazásgazdagép. Futtassa az átvitelt kétszer útvonalanként, és jegyezze fel a teljes időt, a hibák számát és a válaszkészséget, nem egy független sebességteszt kimenetét.

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

Ezek a számok elválasztják a kapcsolatfelépítést az átviteli időtől, ami azért számít, mert a két útvonal általában a körfordulási késleltetésben és az MTU-ban tér el, nem a titkosítás költségében. A TLS-munka mindkét tervben a végpontokon történik, az alagút pedig beágyazást, más útvonalat és esetleg zsúfoltabb átjárót ad hozzá. Ha az alagút útvonala hosszabb, vagy az átjárója terhelt, a különbség az útvonalhoz tartozik, nem a titkosítás szóhoz.

Válassza azt a belépési házirendet, amelyre a szolgáltatásnak valóban szüksége van, majd döntse el, igazolja-e egy mért különbség a megváltoztatását. A nyilvános továbbítás a nyílt internetre szánt szolgáltatáshoz illik, forráskorlátozásokkal, naprakész TLS-sel és előtte lévő megfigyeléssel. A csak alagúton keresztüli hozzáférés olyan belső eszközhöz illik, amelynek felhasználói már regisztrálva vannak, feltéve, hogy az átjáró útválasztása és az alkalmazás engedélyei is szűkebbek, mint az egész LAN.

Mielőtt késznek nyilvánítja a tervet, erősítse meg négy dolgot: melyik címhez van kötve a figyelő, melyik szabály vagy útvonal engedi be a csomagot, működik-e a visszaút az ügyfél valódi címéről, és túlélik-e a nagy hasznos terhek az MTU-t. Mindegyikhez van parancs fent, és egyikre sem a biztonságos szó vagy egy sávszélesség-diagram válaszol.

Kapcsolódó cikkek