Alleen één lokale webservice buiten de VPN routeren op basis van poort

Eén hostdienst moet het internet te woord staan via de fysieke uplink terwijl al het andere op de machine de tunnel blijft gebruiken. Drie voorwaarden bepalen of policy routing die last kan dragen, en elk is goedkoop te controleren voordat je een regel schrijft. De dienst moet op deze host eindigen en niet achter een DNAT of een doorgestuurde poort, de eigen regels van de VPN moeten de uitzondering toestaan, en je moet het antwoord matchen en niet het verzoek. Faalt één van de drie, dan laden de opdrachten hieronder schoon maar doen ze niets nuttigs.

Controleer de drie voorwaarden voordat je een regel schrijft

Een container die een poort via DNAT publiceert, of een server achter een poortdoorschuiving, produceert pakketten die niet op deze host ontstaan. Die pakketten worden doorgestuurd, dus een regel op basis van lokale invoer van de host ziet ze nooit en het verkeer blijft de standaardroute nemen. Bevestig waar de dienst echt draait voordat je verdergaat, want dit is de voorwaarde waar mensen het vaakst de fout in gaan.

De tweede voorwaarde is beleid en niet mechaniek. Elke route die de tunnel omzeilt is een uitzondering op het doel van de tunnel, en op een beheerde host hoort die beslissing bij wie het beleid bezit, niet bij wie een time-out debugt.

Match het antwoord, niet de doelpoort van de client

Een antwoord van een server die op TCP 443 luistert verlaat de host met bronpoort 443. Een browser op dezelfde host die verbinding maakt met een externe HTTPS-site stuurt een kortstondige bronpoort en doelpoort 443. Beide zijn poort-443-verkeer en slechts één ervan zou de WAN-tabel moeten nemen, daarom zou een match op de doelpoort de verkeerde helft pakken.

De antwoordrichting is wat je kunt onderscheiden. Match de bronpoort, beperk de regel tot lokaal gegenereerde pakketten, en de regel dekt de eigen antwoorden van de dienst zonder de verzoeken van de browser aan te raken.

Bouw een volledige retourtabel voordat de regel erop wijst

Een lege tabel betekent geen route, wat eruitziet als een kapotte dienst in plaats van een kapot beleid. Vul hem eerst, met een tabelnummer en prioriteit die niets anders op de host opeist:

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 de nummers van de live host in plaats van ze te kopiëren. ip -4 rule show vertelt je welke prioriteiten bezet zijn, en een regel toevoegen op een prioriteit die al bestaat verandert stil de volgorde van twee regels die er afzonderlijk prima uitzien.

Twee selectors doen hier het echte werk. iif lo is de manier waarop de kernel pakketten meldt die de host zelf heeft gegenereerd, zodat de regel niet per ongeluk doorgestuurd verkeer van buiten vangt. ipproto tcp sport 443 vernauwt het tot één transport en één poort, wat zo strak is als de eis toelaat. Laat de protocolselector weg en de regel vangt ook UDP 443, een andere dienst met ander gedrag.

Houd privé-antwoorden binnen de tunnel

Als dezelfde listener ook clients aan de privékant beantwoordt, zal een WAN-standaardroute die alles vangt in tabel 100 proberen die antwoorden via de uplink terug te sturen. Voeg de privéprefixen toe die de WAN-standaard niet mogen volgen, of laat ze doorvallen naar de volgende beleidsregel:

ip -4 route add table 100 throw 10.90.0.0/24

Een throw-route beëindigt de opzoeking in deze tabel en geeft het pakket terug aan de regellijst, zodat het VPN-beleid dat volgt zijn kans krijgt. Zelf routeert hij niets de tunnel in, en als geen latere regel een passende route heeft, faalt het pakket alsnog; verifieer het volgende beleid in plaats van aan te nemen dat throw een oplossing is.

Reverse-path filtering en firewallregels van de host gelden nog steeds voor het binnenkomende verzoek. Kijk naar hun echte uitspraken voordat je de validatie versoepelt, want een routeringsuitzondering zorgt er niet voor dat rp_filter een retourpad accepteert dat het onmogelijk acht.

Test TCP, dan QUIC, dan een herstart

Open één verbinding van een geautoriseerde externe client en één vanaf de privékant, en bekijk dan de antwoordopzoeking met de werkelijke adressen en poorten. Als het externe antwoord tabel 100 neemt en het privé-antwoord niet, doet het beleid wat je vroeg.

HTTP/3 wordt via UDP geleverd en wordt niet door een TCP-regel gematcht, dus een QUIC-listener heeft zijn eigen selector nodig, anders blijft hij de tunnel gebruiken terwijl HTTPS werkt. Sla de regels waarop je uitkomt op bij de component die de interface bezit, en bevestig ze na een herverbinding of een DHCP-vernieuwing. Wanneer een concurrerende manager na een herstart een runtime-route verwijdert, is dat een eigendomsprobleem dat bij de bron moet worden opgelost, geen reden om bredere NAT-regels erbovenop te leggen.