Bir tokiko web zerbitzu bideratu VPNetik kanpo, portuaren arabera

Host zerbitzu batek interneti erantzun behar dio gorako esteka fisikoaren bidez, makinako gainerako guztiak tunela erabiltzen jarraitzen duen bitartean. Hiru baldintzak erabakitzen dute politikan oinarritutako bideratzeak karga hori jasan dezakeen, eta bakoitza merkea da egiaztatzeko arau bat idatzi aurretik. Zerbitzuak host honetan amaitu behar du, ez DNAT baten edo birbidalitako portu baten atzean, VPNaren beraren arauek salbuespena baimentzen dute, eta erantzuna parekatu behar duzu, ez eskaera. Hiruretako edozein huts eginez gero, beheko komandoak garbi kargatzen dira, baina ez dute ezer erabilgarririk egiten.

Egiaztatu hiru baldintzak arau bat idatzi aurretik

Portu bat DNAT bidez argitaratzen duen edukiontziak, edo portu-birbidalketa baten atzean dagoen zerbitzariak, host honetan sortzen ez diren paketeak sortzen ditu. Pakete horiek birbidali egiten dira, beraz hosteko sarrera lokalera lotutako arau batek ez ditu inoiz ikusten eta trafikoak lehenetsitako ibilbidea hartzen jarraitzen du. Egiaztatu zerbitzua benetan non exekutatzen den aurrera egin aurretik, hori baita jendeak sarrien oker ulertzen duen baldintza.

Bigarren baldintza politika da, ez mekanika. Tunela saihesten duen edozein ibilbide tunelaren helburuaren salbuespena da, eta kudeatutako host batean erabaki hori politikaren jabearena da, ez denbora-muga arazten ari den pertsonarena.

Parekatu erantzuna, ez bezeroaren helmuga-portua

TCP 443n entzuten duen zerbitzariaren erantzunak hostetik irteten da iturburu-portua 443 duela. Host bereko nabigatzaileak urruneko HTTPS gune batera konektatzean iturburu-portu efimeroa eta helmuga-portua 443 bidaltzen ditu. Biak 443 portuko trafikoak dira eta horietako batek soilik erabili behar du WAN taula, eta horregatik helmuga-portuaren parekatzeak erdi okerra harrapatuko luke.

Erantzunaren noranzkoa da bereizi dezakezun gauza. Parekatu iturburu-portua, mugatu araua lokalki sortutako paketeetara, eta arauak zerbitzuaren erantzun propioak estaltzen ditu nabigatzailearen eskakizunei ukitu gabe.

Eraiki itzultze-taula oso bat arauak hara seinalatu aurretik

Taula hutsak esan nahi du ibilbiderik ez, eta hori zerbitzu hautsia bezala ikusten da, ez politika hautsia. Bete ezazu lehenengo, hostean beste ezerk aldarrikatzen ez duen taula-zenbaki eta lehentasunarekin:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Irakurri zenbakiak zuzenean hostetik, kopiatu beharrean. ip -4 rule show gainean dauden lehentasunak esaten dizkizu, eta jada existitzen den lehentasun batean arau bat gehitzeak isilpean aldatzen du bere horretan ondo ikusten diren bi arauren ordena.

Hemen bi hautatzailek egiten dute benetako lana. iif lo nukleoak hostak berak sortutako paketeak nola jakinarazten dituen da, beraz arauak ezin du kanpotik datorren birbidalitako trafikoa ustekabean harrapatu. ipproto tcp sport 443 garraio bakar eta portu bakarrera murrizten du, eta hori da baldintzak uzten duen bezain estua. Kendu protokolo-hautatzailea eta arauak UDP 443 ere harrapatuko du, zeina beste zerbitzu bat den, beste jokaera batekin.

Mantendu erantzun pribatuak tunelean barruan

Entzule berak alde pribatuko bezeroei ere erantzuten badie, 100 taulan guztia harrapatzen duen WAN lehenetsitako ibilbide batek gorako estekaren bidez itzultzen saiatuko da erantzun horiek. Gehitu WAN lehenetsia jarraitu behar ez duten aurrizki pribatuak, edo utzi hurrengo politika-araura erortzen:

ip -4 route add table 100 throw 10.90.0.0/24

Throw ibilbide batek taula honetako bilaketa amaitzen du eta paketea arauen zerrendari itzultzen dio, beraz ondoren datorren VPN politikak bere aukera hartzen du. Berak ez du ezer tunelera bideratzen, eta geroagoko arau batek bat etortzen den ibilbiderik ez badu, paketeak huts egiten du oraindik; egiaztatu hurrengo politika, throw konponbidea dela suposatu beharrean.

Alderantzizko bidearen iragazketak eta hosteko suebakiaren arauek oraindik ere aplikatzen zaizkio iristen den eskaerari. Begiratu haien benetako epaiak balidazioa lasaitu aurretik, bideratze-salbuespen batek ez baitu lortzen rp_filter ezinezkoa iruditzen zaion itzulera-bide bat onar dezan.

Probatu TCP, gero QUIC, gero berrabiaraztea

Ireki konexio bat baimendutako kanpoko bezero batetik eta beste bat alde pribatutik, eta gero ikuskatu erantzunaren bilaketa benetako helbide eta portuekin. Kanpoko erantzunak 100 taula hartzen badu eta pribatuak ez, politikak eskatutakoa egiten du.

HTTP/3 UDP bidez zerbitzatzen da eta TCP arau batek ez du bat egingo, beraz QUIC entzule batek bere hautatzailea behar du, bestela tuneletik jarraituko du HTTPSk funtzionatzen duen bitartean. Gorde erabakitzen dituzun arauak interfazearen jabea den osagaian, eta berretsi berriz konektatu edo DHCP berritze baten ondoren. Kudeatzaile lehiakide batek exekuzio-denbora ibilbide bat kentzen badu berrabiarazte baten ondoren, jabetza-arazo bat da, iturburuan konpondu beharrekoa, ez NAT arau zabalagoak gainean jartzeko arrazoia.