Stuur net een plaaslike webdiens op poortbasis verby die VPN

Een gasheerdiens moet die internet oor die fisiese opwaartse skakel antwoord terwyl alles anders op die masjien die tonnel bly gebruik. Drie voorwaardes bepaal of beleidsroetering daardie las kan dra, en elkeen is goedkoop om na te gaan voordat jy ’n reël skryf. Die diens moet op hierdie gasheer eindig, nie agter ’n DNAT of ’n aangestuurde poort nie, die VPN se eie reëls moet die uitsondering toelaat, en jy moet die antwoord pas, nie die versoek nie. Faal enige van die drie en die opdragte hieronder laai skoon terwyl hulle niks nuttigs doen.

Gaan die drie voorwaardes na voordat jy ’n reël skryf

’n Houer wat ’n poort deur DNAT publiseer, of ’n bediener agter ’n poortaanstuur, lewer pakkette wat nie op hierdie gasheer ontstaan nie. Daardie pakkette word aangestuur, so ’n reël wat op gasheerplaaslike inset sleutel, sien hulle nooit en die verkeer bly die verstekroete volg. Bevestig waar die diens werklik loop voordat jy voortgaan, want dit is die voorwaarde wat mense die meeste verkeerd kry.

Die tweede voorwaarde is beleid, nie meganika nie. Enige roete wat die tonnel omseil, is ’n uitsondering op die tonnel se doel, en op ’n bestuurde gasheer hoort daardie besluit by wie die beleid besit, nie by die persoon wat ’n tydsverloop ontfout nie.

Pas die antwoord, nie die kliënt se bestemmingspoort nie

’n Antwoord van ’n bediener wat op TCP 443 luister, verlaat die gasheer met bronpoort 443. ’n Blaaier op dieselfde gasheer wat na ’n afgeleë HTTPS-werf verbind, stuur ’n kortstondige bronpoort en bestemmingspoort 443. Albei is poort-443-verkeer en net een daarvan moet die WAN-tabel gebruik, en daarom sou ’n bestemmingspoortpassing die verkeerde helfte gryp.

Die antwoordrigting is wat jy kan onderskei. Pas die bronpoort, beperk die reël tot plaaslik gegenereerde pakkette, en die reël dek die diens se eie antwoorde sonder om aan die blaaier se versoeke te raak.

Bou ’n volledige retourtabel voordat die reël daarheen wys

’n Leë tabel beteken geen roete nie, wat soos ’n stukkende diens lyk eerder as ’n stukkende beleid. Vul dit eers, met ’n tabelnommer en prioriteit wat niks anders op die gasheer opeis nie:

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

Lees die nommers van die lewendige gasheer af eerder as om dit te kopieer. ip -4 rule show vertel jou watter prioriteite geneem is, en om ’n reël by ’n prioriteit te voeg wat reeds bestaan, verander stilweg die volgorde van twee reëls wat elkeen op sigself reg lyk.

Twee keurders doen hier die regte werk. iif lo is hoe die kern pakkette rapporteer wat die gasheer self gegenereer het, so die reël kan nie per ongeluk aangestuurde verkeer van buite vang nie. ipproto tcp sport 443 vernou dit tot een transport en een poort, wat so streng is as wat die vereiste toelaat. Los die protokolkeurder weg en die reël gryp ook UDP 443, wat ’n ander diens met ander gedrag is.

Hou private antwoorde binne die tonnel

As dieselfde luisteraar ook kliënte aan die privaatkant antwoord, sal ’n alle-gevalle WAN-verstek in tabel 100 daardie antwoorde deur die opwaartse skakel probeer terugstuur. Voeg die private voorvoegsels by wat nie die WAN-verstek moet volg nie, of laat hulle na die volgende beleidsreël deurval:

ip -4 route add table 100 throw 10.90.0.0/24

’n Gooi-roete beëindig die soektog in hierdie tabel en gee die pakket terug aan die reëllvs, so die VPN-beleid wat volg kry sy kans. Dit roeteer self niks in die tonnel in nie, en as geen latere reël ’n passende roete het nie, faal die pakket steeds; verifieer die volgende beleid eerder as om aan te neem die gooi is ’n oplossing.

Omgekeerde-pad-filtrering en gasheer-brandmuurreëls geld steeds vir die aankomende versoek. Kyk na hulle werklike uitsprake voordat jy validering verslap, want ’n roete-uitsondering maak nie dat rp_filter ’n terugkeerpad aanvaar wat dit onmoontlik ag nie.

Toets TCP, dan QUIC, dan ’n herstart

Maak een verbinding van ’n gemagtigde eksterne kliënt en een van die privaatkant oop, en ondersoek dan die antwoordsoektog met die werklike adresse en poorte. As die eksterne antwoord tabel 100 gebruik en die private antwoord nie, doen die beleid wat jy gevra het.

HTTP/3 word oor UDP bedien en sal nie deur ’n TCP-reël gepas word nie, so ’n QUIC-luisteraar het sy eie keurder nodig, anders bly hy die tonnel gebruik terwyl HTTPS werk. Bewaar watter reëls jy ook al kies by die komponent wat die koppelvlak besit, en bevestig hulle ná ’n herverbinding of ’n DHCP-hernuwing. Wanneer ’n mededingende bestuurder ’n looptydroete ná ’n herstart verwyder, is dit ’n eienaarskapprobleem om by die bron op te los, nie ’n rede om breër NAT-reëls bo-op te voeg nie.