Samma server-IP, två vägar: markera OpenVPN:s yttre flöde

Det vanliga slingskyddet är en värdrutt: skicka trafik till VPN-serverns publika adress ut via upplänken så att den krypterade sessionen aldrig hamnar i sin egen tunnel. Det fungerar ända till det ögonblick då du också vill nå en webbtjänst på samma server genom tunneln, eftersom undantaget är knutet till destinationen och destinationen är identisk. Vägen ut är att sluta klassificera efter destination och i stället klassificera efter vilken socket som skickade paketet.

Börja med de två flöden du vill skilja åt

Det ena flödet är den krypterade OpenVPN-transporten själv, som måste lämna via upplänken, annars skulle tunneln bära sin egen yttre anslutning. Det andra är en vanlig HTTPS-begäran till samma publika adress, som du vill ha inne i tunneln så att den når tjänsten från en tunnelkälla. Samma destination, i många fall samma portnummer, olika krävd väg.

I den här genomgången antar vi en klient på 10.90.0.10 över tun1, en publik serveradress på 198.51.100.25 och en orörd huvudtabell vars standard pekar på den vanliga upplänken. Serversidan måste också acceptera webbtjänsten på den inre vägen och skicka tillbaka trafik till tunnelkällan; att skicka ett paket till en publik adress åsidosätter inte serverns lyssnare eller brandväggsregler.

Innan du ändrar något, dokumentera värdens nuvarande regler och välj värden som ingen annan använder: en markering, ett tabellnummer och tre regelprioriteter. Behåll en väg tillbaka in i maskinen som inte går över den här anslutningen, eftersom ett misstag här tar bort din egen fjärråtkomst i stället för att bara förstöra en webbläsarflik.

Markera socketen som bär höljet

Klientkonfigurationen får en markering för sina krypterade utgående paket och slutar installera rutter själv, så att ersättningspolicyn är det enda som bestämmer vägarna:

mark 42
route-noexec
disable-dco

Decimalt 42 är hexadecimalt 0x2a, och det är hexformen som routingreglerna matchar. Referensen för link-options beskriver mark som något som gäller krypterade utgående paket på Linux, vilket är precis den socket vars väg du behöver styra. Att stänga av datakanalens offload håller exemplet på userspace-vägen, där markeringsbeteendet är det som beskrivs.

route-noexec undertrycker OpenVPN:s automatiska tillägg och borttagning av rutter. Det installerar inget i deras ställe, så från denna stund måste ruttägaren underhålla varje rutt som tunneln behöver. Om en privat destination försvinner efter ändringen är det den saknade ersättningspolicyn, inte ett fel i markeringen.

Behåll ingen värdrutt i huvudtabellen för 198.51.100.25 medan du gör detta. En sådan rutt återinför precis det undantag som designen försöker minska, och den vinner för HTTPS-flödet innan någon av policyerna nedan konsulteras.

Skicka allt annat till tunneltabellen

När tunnelgränssnittet finns och har sin adress ser policyn ut så här:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

Den första regeln håller värdens specifika rutter synliga, inklusive ett godkänt lokalt nätverk, samtidigt som den gör huvudtabellens standardrutt osynlig för den här sökningen. Den skillnaden spelar roll: att undertrycka standarden är inte samma sak som att ignorera tabellen, och de lokala undantag du fortfarande behöver överlever just därför. Läs undantagen ett i taget i stället för att anta att resultatet är en universell nödstopp.

Omarkerad trafik faller då till tunneltabellen, tar tunnelkällan och lämnar via VPN. Markerad trafik misslyckas i fwmark-testet på de två följande reglerna och fortsätter till den vanliga huvudsökningen längre ner i listan, där upplänkens standard fortfarande ligger. Den avslutande unreachable-regeln är det som hindrar ett omarkerat flöde från att tyst falla tillbaka på upplänken när tunnelrutten saknas. Väljaren är markeringen från början till slut, och destinationsadressen ingår aldrig i beslutet.

Håll den spärren på plats över frånkopplingar och installera den tillsammans med resten av policyn i stället för för hand. En regel som försvinner med gränssnittet är ingen policy, det är en slump. Att radera policyn när tunneln faller ändrar felläget från ”blockerat” till ”läckt”, och en inaktuell tunnelrutt som senare löper ut är ett mycket lättare problem att förklara än trafik som lämnade via fel gränssnitt.

Låt returvägen se samma markering

Utgående markeringar är bara halva mekanismen, och det är den del som de flesta återskapanden utelämnar. Svar på den krypterade sessionen anländer på upplänken och omfattas av reverse-path-validering, som frågar om källan skulle routas tillbaka samma väg som den kom. Utan hjälp tillämpar den sökningen din omarkerade tunnelpolicy och drar slutsatsen att paketet är på fel gränssnitt.

Rättelsen tillhör brandväggsägaren: spara markeringen på den utgående anslutningen, återställ den på matchande inkommande paket och aktivera källvaliderad markeringshantering för den aktuella vägen. Att OpenVPN sätter en socketmarkering gör ingen av de tre sakerna, och ett recept som bara listar klientalternativen är ofullständigt. Begär den integrationen skriftligt, eftersom den är designens minst synliga del och den lättaste att tappa bort vid en ombyggnad.

Lös reverse-path-kontroll är inte heller någon ersättning. Löst läge behöver fortfarande någon rutt för källan, och den unreachable-spärr du lade till tar medvetet bort en för omarkerade sökningar. Låt integrationen av anslutningsmarkeringen bli klar och granskad innan du litar på den här designen, och behandla värdilter som en separat fråga: en markering är en routingsignal, inte ett tillstånd. Saknas integrationen är symtomet en session som etableras och sedan tystnar så snart svar börjar anlända.

Bevisa det med två ruttuppslagningar

Jämför vad kärnan beslutar för de två sammanhangen och läs fälten dev och src i stället för exitstatus:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

Den första uppslagningen bör leda till tun1 med tunnelkällan och den andra till upplänken. Det är syntetiska uppslagningar, så de bevisar policyn och inte den körande processen: bekräfta den körande klientens faktiska transportväg separat och gör sedan en riktig HTTPS-begäran med certifikatverifiering påslagen.

Skriv ner vad designen inte täcker innan du förklarar den klar. DNS, IPv6 och reglernas livscykel behöver var sitt beslut, och det här är ett IPv4-routingexempel snarare än en fullständig integritetskonfiguration. Dess värde är väljaren: höljet får upplänksundantaget, och en vanlig tjänst på samma adress behöver inte ärva det.