Portforwarding tsjin VPN-toegong: wêr't it pakket eins hinne giet

In portforwarding skriuwt de bestimming oer en stoppet dêr; in VPN pakket it pakket earst yn. Sjoch hokker laach elk feroaret en wat dat foar HTTPS betsjut.

Twa ûntwerpen, ien HTTPS-applikaasje, en it pakket nimt yn elk in oare rûte. In portforwarding feroaret wêr't it pakket ôflevere wurdt en lit de rest gewurde. In VPN draacht it pakket earst yn in oar pakket, sadat de listener fan 'e applikaasje in oare boarne en in lytsere maksimale lading sjocht. De fersifering dêr't minsken oer diskusjearje is yn beide gefallen oanwêzich, om't de applikaasje noch altyd HTTPS is; wat ferskilt, is wa't in ferbining iepenje kin en wat it netwurk dertusken observearje kin. Dat ferskil beslist de measte praktyske fragen.

De DNAT-regel skriuwt de bestimming oer en stoppet dêr

Op in Linux-gateway betsjut it publisearjen fan in tsjinst in regel yn 'e PREROUTING-keten fan 'e nat-tabel, of it ekwivalint yn nftables. De regel matcht it iepenbiere adres en de poarte, en skriuwt dan de bestimming oer nei it privee adres fan 'e applikaasje. Boarneadres, boarnepoarte en lading bliuwe ûnoantaast, en conntrack registrearret de mapping sadat antwurden by it útgong werom skreaun wurde. It gedrach is it tradisjonele adresoersetmodell dat yn RFC 3022 beskreaun wurdt.

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

De listener fan 'e applikaasje leart nea dat de ferbining troch in oersetting binnenkaam. Hy sjocht it echte boarneadres fan 'e klant, wat nuttich is foar tagongslogs en taryflimiten, en hy antwurdet op it privee adres om't conntrack de mapping omkeart. Neat op dy rûte ûntsiferet of fersiferet opnij: TLS rint noch altyd tusken de klant en it eigen sertifikaat fan 'e applikaasje.

De regel fêstiget ek de flatermodi dy't jo letter tsjinkomme. As de gateway trochstjoert mar de host fan 'e applikaasje hat gjin weromrûte nei de klant, geane antwurden mei de ferkearde boarne fuort en de handshake stoppet. As in twadde regel earst matcht, beslissit de oarder it resultaat, en iptables -t nat -L -n -v toant de tellers dy't bewize hokker regel it pakket naam.

De tunnel pakket it pakket yn foardat de listener it sjocht

In VPN publisearret de applikaasje hielendal net. De klant bout in bûtenste pakket rjochte op it iepenbiere adres fan 'e gateway, fersiferet it binnenste pakket deryn, en de gateway ûntsiferet en rûtes it binnenste pakket nei de privee bestimming. By WireGuard is it bûtenste transport UDP, meast op in hege poarte; by OpenVPN oer TCP 443 liket it bûtenste pakket op TLS foar alles wat de rûte besjocht.

Yn 'e tunnel hâldt it binnenste pakket privee adressen: it tunneladres fan 'e klant, sis 10.8.0.6, en de applikaasje op 10.20.30.40. De listener sjocht dêrom in boarne út 'e tunnelpool, en elke klant dielt dy gateway as folgjende hop. Tagongslogs efter in VPN toane faak de gateway ynstee fan 'e brûker krekt om dizze reden, útsein as de gateway de oarspronklike boarne bewarret.

It ynpakken kostet kopromte, en dat is it iennige ferskil op meganismenivo mei in mjitber gefolch. In bûtenste IP-kop plus UDP plus WireGuard syn eigen kop frette fan 'e MTU fan 'e rûte, dus grutte pakketten moatte fragmintearre wurde of de binnenste TCP-stapel moat syn MSS beheine. In oerdracht dy't oer it trochstjoerde paad wurket, kin oer de tunnel fêstrinne as in tuskenapparaat de ICMP weilitten dy't de lytsere MTU oanjûn hie.

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

Bleatstelling wurdt by de yngong besletten, net troch it sjifer

Beide ûntwerpen einigje by deselde TLS-listener, dus beide ervje itselde sertifikaat, deselde protokolferzjes en deselde applikaasjelogin. Wat feroaret, is wa't in handshake begjinne mei. Mei in iepenbiere trochstjoering krijt elke host dy't 203.0.113.10:443 berikt in TCP-handshake en in TLS ClientHello foardat jo applikaasje-autorisearring ea besjoen wurdt. Mei tagong allinnich fia tunnel is de listener allinnich berikber fan adressen dy't de gateway de tunnel yn rûtes, en de SYN fan in frjemdling stjert by it gatewaybelied.

Dat ferskil giet oer berikberens, net oer fertroulikheid. In trochstjoerde HTTPS-tsjinst is gjin platte tekst, en in VPN hellet de needsaak foar applikaasje-autentikaasje net fuort: tunnelopname antwurdet oft in apparaat pakketten yn dit netwurk stjoere mei, wylst de triemapplikaasje antwurdet oft in brûker in dokumint lêze mei. It beiden trochinoar smite is hoe't teams einigje mei in VPN dy't it hiele LAN jout en in applikaasje mei ien dield wachtwurd.

Undersykje de listener en it belied apart, want elk fan beide kin breder wêze as jo tinke:

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

As ss toant dat de listener oan 0.0.0.0 bûn is, is de applikaasje berikber fan wêr't rûtering en firewallbelied it tastean, en de trochstjoering is mar ien fan 'e wegen nei binnen. Bine oan it privee adres, of it beheinen fan it boarneberik yn 'e firewall, is in aparte beslissing fan it kiezen fan in VPN, en it is de beslissing dy't de bleatstelling echt ferlytset.

Mjit it paad, net it label

As immen beweart dat de trochstjoering flugger is, hâldt de earlike ferliking al it oare konstant: deselde klant, itselde tagongsnetwurk, itselde triem, deselde TLS-konfiguraasje, deselde applikaasjehost. Rin de oerdracht twa kear per paad en skriuw totale tiid, oantal flaters en reaksjefermogen op, net de útfier fan in net besibbe fluggensstest.

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

Dy sifers skiede ferbiningopsetsel fan oerdrachtstiid, wat fan belang is om't de twa paden meastal ferskille yn rûnreisfertraging en MTU, net yn sjiferkosten. TLS-wurk bart by de einpunten yn beide ûntwerpen, en in tunnel foeget ynkapseling, in oare rûte en miskien in drokker gateway ta. As it tunnelpaad langer is of syn gateway is belêste, heart it ferskil by it paad en net by it wurd fersifering.

Kies it yngongsbelied dat de tsjinst echt nedich hat, en beslút dan oft in mjitten ferskil it rjochtfeardiget om it te feroarjen. In iepenbiere trochstjoering past by in tsjinst foar it iepen ynternet, mei boarnebeheiningen, bywurke TLS en tafersjoch derfoar. Tagong allinnich fia tunnel past by in yntern ark waans brûkers al ynskreaun binne, mits de rûtering fan 'e gateway en de rjochten fan 'e applikaasje beide smeller binne as it hiele LAN.

Foardat jo it ûntwerp klear neame, befêstigje fjouwer dingen: hokker adres de listener oan bûn is, hokker regel of rûte it pakket talit, oft de weromrûte fan it echte adres fan 'e klant wurket, en oft grutte ladingen de MTU oerlibje. Elk dêrfan hat in opdracht hjirboppe, en gjinien wurdt beantwurde troch it wurd feilich of troch in bânbreedtegrafyk.

Relatearre artikelen