Portinohjaus vastaan VPN-yhteys: minne paketti todella menee

Portinohjaus kirjoittaa kohteen uudelleen ja pysähtyy siihen; VPN käärii paketin ensin. Katso, mitä kerrosta kumpikin muuttaa ja mitä se tarkoittaa HTTPS:lle.

Kaksi mallia, yksi HTTPS-sovellus, ja paketti kulkee kummassakin eri reittiä. Portinohjaus muuttaa, minne paketti toimitetaan, ja jättää muun rauhaan. VPN kantaa paketin ensin toisen paketin sisällä, joten sovelluksen kuuntelija näkee eri lähteen ja pienemmän suurimman hyötykuorman. Salaus, josta ihmiset väittelevät, on läsnä molemmissa tapauksissa, koska sovellus on edelleen HTTPS; ero on siinä, kuka voi avata yhteyden ja mitä välissä oleva verkko voi havaita. Tämä ero ratkaisee useimmat käytännön kysymykset.

DNAT-sääntö kirjoittaa kohteen uudelleen ja pysähtyy siihen

Linux-yhdyskäytävässä palvelun julkaiseminen tarkoittaa sääntöä nat-taulun PREROUTING-ketjussa tai vastaavaa nftablesissa. Sääntö täsmää julkiseen osoitteeseen ja porttiin ja kirjoittaa sitten kohteen uudelleen sovelluksen yksityiseen osoitteeseen. Lähdeosoite, lähdeportti ja hyötykuorma pysyvät koskemattomina, ja conntrack tallentaa kuvauksen, jotta vastaukset kirjoitetaan takaisin ulos lähtiessä. Toiminta on perinteinen osoitteenmuunnosmalli, jota kuvataan dokumentissa 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

Sovelluksen kuuntelija ei koskaan saa tietää, että yhteys saapui muunnoksen kautta. Se näkee asiakkaan todellisen lähdeosoitteen, mikä on hyödyllistä käyttölokeille ja nopeusrajoituksille, ja vastaa yksityiseen osoitteeseen, koska conntrack kääntää kuvauksen. Mikään tällä reitillä ei salaa purkamatta tai salaa uudelleen: TLS toimii edelleen asiakkaan ja sovelluksen oman varmenteen välillä.

Sääntö määrää myös vikatilat, joihin myöhemmin törmäät. Jos yhdyskäytävä välittää, mutta sovelluksen isännällä ei ole paluureittiä asiakkaalle, vastaukset lähtevät väärällä lähteellä ja kättely pysähtyy. Jos toinen sääntö täsmää ensin, järjestys ratkaisee tuloksen, ja iptables -t nat -L -n -v näyttää laskurit, jotka todistavat, mikä sääntö otti paketin.

Tunneli käärii paketin ennen kuin kuuntelija näkee sen

VPN ei julkaise sovellusta lainkaan. Asiakas rakentaa ulomman paketin, joka on osoitettu yhdyskäytävän julkiseen osoitteeseen, salaa sisemmän paketin sen sisään, ja yhdyskäytävä purkaa salauksen ja reitittää sisemmän paketin yksityiseen kohteeseen. WireGuardissa ulompi kuljetus on UDP, tavallisesti korkealla portilla; kun OpenVPN kulkee TCP 443:n yli ulompi paketti näyttää TLS:ltä kaikelle, mikä reittiä tarkkailee.

Tunnelin sisällä sisempi paketti säilyttää yksityiset osoitteet: asiakkaan tunneliosoite, sanotaan 10.8.0.6, ja sovellus osoitteessa 10.20.30.40. Siksi kuuntelija näkee lähteen tunnelipoolista, ja jokainen asiakas jakaa tuon yhdyskäytävän seuraavana hyppynä. VPN:n takana käyttölokit näyttävät usein yhdyskäytävän käyttäjän sijaan juuri tästä syystä, ellei yhdyskäytävä säilytä alkuperäistä lähdettä.

Kääriminen maksaa otsikkotilaa, ja se on ainoa mekanismitason ero, jolla on mitattava seuraus. Ulompi IP-otsikko plus UDP plus WireGuardin oma otsikko syövät reitin MTU:ta, joten suuret paketit on pilkottava tai sisemmän TCP-pinon on rajoitettava MSS:äänsä. Siirto, joka toimii ohjatulla reitillä, voi juuttua tunnelissa, kun välilaite pudottaa ICMP:n, joka olisi ilmoittanut pienemmästä MTU:sta.

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

Altistuminen ratkaistaan sisäänkäynnillä, ei salauksella

Molemmat mallit päättyvät samaan TLS-kuuntelijaan, joten molemmat perivät saman varmenteen, samat protokollaversiot ja saman sovelluskirjautumisen. Muuttuu se, kuka saa aloittaa kättelyn. Julkisessa ohjauksessa jokainen isäntä, joka tavoittaa osoitteen 203.0.113.10:443, saa TCP-kättelyn ja TLS ClientHellon ennen kuin sovelluksesi valtuutusta edes tarkastellaan. Vain tunnelin kautta tapahtuvassa yhteydessä kuuntelija on tavoitettavissa vain osoitteista, jotka yhdyskäytävä reitittää tunneliin, ja vieraan SYN kuolee yhdyskäytävän käytäntöön.

Ero koskee tavoitettavuutta, ei luottamuksellisuutta. Ohjattu HTTPS-palvelu ei ole selkokielistä, eikä VPN poista sovelluksen todennuksen tarvetta: tunnelin hyväksyntä vastaa siihen, saako laite lähettää paketteja tähän verkkoon, kun taas tiedostosovellus vastaa siihen, saako käyttäjä lukea asiakirjan. Näiden kahden sekoittaminen johtaa siihen, että tiimeillä on VPN, joka antaa koko lähiverkon, ja sovellus, jossa on yksi jaettu salasana.

Tarkastele kuuntelija ja käytäntö erikseen, sillä kumpi tahansa voi olla laajempi kuin oletat:

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

Jos ss näyttää, että kuuntelija on sidottu osoitteeseen 0.0.0.0, sovellus on tavoitettavissa kaikkialta, mihin reititys ja palomuurikäytäntö sen sallivat, ja ohjaus on vain yksi sisäänkäynti. Sidonta yksityiseen osoitteeseen tai lähdealueen rajaaminen palomuurissa on VPN:n valinnasta erillinen päätös, ja juuri se päätös kaventaa altistumista.

Mittaa reittiä, älä nimikettä

Kun joku väittää ohjauksen olevan nopeampi, rehellinen vertailu pitää kaiken muun vakiona: sama asiakas, sama käyttöverkko, sama tiedosto, sama TLS-kokoonpano, sama sovellusisäntä. Aja siirto kahdesti reittiä kohden ja kirjaa kokonaisaika, virheiden määrä ja responsiivisuus, älä irrallisen nopeustestin tulosta.

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

Nämä luvut erottavat yhteyden muodostuksen siirtoajasta, millä on merkitystä, koska kaksi reittiä eroavat yleensä edestakaisessa viiveessä ja MTU:ssa, eivät salauksen kustannuksessa. TLS-työ tapahtuu päätepisteissä molemmissa malleissa, ja tunneli lisää kapseloinnin, eri reitin ja mahdollisesti kiireisemmän yhdyskäytävän. Jos tunnelireitti on pidempi tai sen yhdyskäytävä on kuormitettu, ero kuuluu reitille eikä sanalle salaus.

Valitse sisäänkäyntikäytäntö, jonka palvelu todella tarvitsee, ja päätä sitten, oikeuttaako mitattu ero sen muuttamisen. Julkinen ohjaus sopii avoimelle internetille tarkoitetulle palvelulle, jossa on lähderajoitukset, ajan tasalla oleva TLS ja valvonta edessä. Vain tunnelin kautta tapahtuva yhteys sopii sisäiseen työkaluun, jonka käyttäjät on jo rekisteröity, edellyttäen että yhdyskäytävän reititys ja sovelluksen käyttöoikeudet ovat molemmat koko lähiverkkoa kapeammat.

Ennen kuin kutsut mallin valmiiksi, vahvista neljä asiaa: mihin osoitteeseen kuuntelija on sidottu, mikä sääntö tai reitti päästää paketin sisään, toimiiko paluureitti asiakkaan todellisesta osoitteesta ja selviävätkö suuret hyötykuormat MTU:sta. Jokaiselle niistä on komento yllä, eikä yhteenkään vastaa sana turvallinen tai kaistanleveyskaavio.

Aiheeseen liittyvät artikkelit