Rut kun én lokal webtjeneste uden om VPN'et efter port

Én værtstjeneste skal svare internettet over det fysiske uplink, mens alt andet på maskinen fortsætter med at bruge tunnelen. Tre betingelser afgør, om policy-routing kan bære den belastning, og hver af dem er billig at kontrollere, inden du skriver en regel. Tjenesten skal afsluttes på denne vært og ikke bag en DNAT eller en videresendt port, VPN'ets egne regler skal tillade undtagelsen, og du skal matche svaret i stedet for forespørgslen. Fejler blot én af de tre, indlæses kommandoerne nedenfor uden fejl, men gør intet nyttigt.

Kontroller de tre betingelser, inden du skriver en regel

En container, der udgiver en port via DNAT, eller en server bag en portvideresendelse, producerer pakker, der ikke opstår på denne vært. De pakker videresendes, så en regel bundet til værtslokal input ser dem aldrig og trafikken bliver ved med at tage standardruten. Bekræft, hvor tjenesten faktisk kører, inden du fortsætter, for det er den betingelse, folk oftest tager fejl af.

Den anden betingelse er politik og ikke mekanik. Enhver rute, der omgår tunnelen, er en undtagelse fra tunnelens formål, og på en administreret vært tilhører den beslutning den, der ejer politikken, ikke den, der fejlfinder en timeout.

Match svaret, ikke klientens destinationsport

Et svar fra en server, der lytter på TCP 443, forlader værten med kildeport 443. En browser på samme vært, der forbinder til et eksternt HTTPS-websted, sender en efemær kildeport og destinationsport 443. Begge er port-443-trafik, og kun én af dem bør tage WAN-tabellen, og derfor ville et match på destinationsporten gribe den forkerte halvdel.

Svarretningen er det, du kan skelne. Match kildeporten, begræns reglen til lokalt genererede pakker, og reglen dækker tjenestens egne svar uden at røre browserens forespørgsler.

Byg en komplet returtabel, før reglen peger på den

En tom tabel betyder ingen rute, hvilket ser ud som en brudt tjeneste snarere end en brudt politik. Fyld den først med et tabelnummer og en prioritet, som intet andet på værten gør krav på:

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

Læs tallene fra den kørende vært i stedet for at kopiere dem. ip -4 rule show fortæller dig, hvilke prioriteter der er taget, og at tilføje en regel på en prioritet, der allerede findes, ændrer lydløst rækkefølgen af to regler, der hver for sig ser fine ud.

To selektorer gør det egentlige arbejde her. iif lo er måden, kernelen rapporterer pakker, som værten selv har genereret, så reglen kan ikke ved et uheld fange videresendt trafik, der kommer udefra. ipproto tcp sport 443 indsnævrer det til én transport og én port, hvilket er så stramt, som kravet tillader. Fjern protokolselektoren, og reglen fanger også UDP 443, som er en anden tjeneste med en anden adfærd.

Hold private svar inde i tunnelen

Hvis den samme lytter også svarer klienter på den private side, vil en WAN-standardrute, der fanger alt, i tabel 100 forsøge at sende de svar tilbage over uplink. Tilføj de private præfikser, der ikke må følge WAN-standarden, eller lad dem falde videre til den næste politikregel:

ip -4 route add table 100 throw 10.90.0.0/24

En throw-rute afslutter opslaget i denne tabel og giver pakken tilbage til regellisten, så den VPN-politik, der følger, får sin chance. Den ruter ikke selv noget ind i tunnelen, og hvis ingen senere regel har en matchende rute, fejler pakken stadig; verificér den næste politik i stedet for at antage, at throw er en løsning.

Filtrering af omvendt sti og værtens firewallregler gælder stadig for den ankommende forespørgsel. Se på deres faktiske afgørelser, før du lemper valideringen, for en undtagelse i routingen får ikke rp_filter til at acceptere en retursti, den anser for umulig.

Test TCP, derefter QUIC, derefter en genstart

Åbn én forbindelse fra en autoriseret ekstern klient og én fra den private side, og inspicér derefter svaropslaget med de faktiske adresser og porte. Hvis det eksterne svar tager tabel 100, og det private ikke gør, gør politikken, hvad du bad om.

HTTP/3 leveres over UDP og vil ikke blive matchet af en TCP-regel, så en QUIC-lytter har brug for sin egen selektor, ellers bliver den ved med at bruge tunnelen, mens HTTPS virker. Gem de regler, du lander på, hos den komponent, der ejer interfacet, og bekræft dem efter en genopkobling eller en DHCP-fornyelse. Når en konkurrerende manager fjerner en runtime-rute efter en genstart, er det et ejerskabsproblem, der skal løses ved kilden, ikke en grund til at lægge bredere NAT-regler ovenpå.