Samme server-IP, to veje: markering af OpenVPNs ydre flow

Den sædvanlige løkkebeskyttelse er en værtsrute: send trafik til VPN-serverens offentlige adresse ud ad uplink'en, så den krypterede session aldrig ender i sin egen tunnel. Det virker lige indtil det øjeblik, hvor du også vil nå en webtjeneste på samme server gennem tunnelen, fordi undtagelsen er bundet til destinationen, og destinationen er identisk. Vejen ud er at holde op med at klassificere efter destination og i stedet klassificere efter hvilken socket der sendte pakken.

Start med de to flows, du vil skille ad

Den ene flow er den krypterede OpenVPN-transport selv, som skal forlade systemet via uplink'en, ellers ville tunnelen bære sin egen ydre forbindelse. Den anden er en almindelig HTTPS-anmodning til den samme offentlige adresse, som du vil have inde i tunnelen, så den ankommer til tjenesten fra en tunnelkilde. Samme destination, i mange tilfælde samme portnummer, forskellig påkrævet vej.

I denne gennemgang antages en klient på 10.90.0.10 over tun1, en server-offentlig adresse på 198.51.100.25 og en urørt hovedtabel, hvis standard peger på den almindelige uplink. Serversiden skal også acceptere webtjenesten på den indre vej og sende trafik tilbage til tunnelkilden; at sende en pakke til en offentlig adresse tilsidesætter ikke serverens listener eller firewallpolitik.

Før du ændrer noget, skal du registrere værtens nuværende regler og vælge værdier, som ingen andre bruger: et mærke, et tabelnummer og tre regelprioriteter. Behold en adgang tilbage til maskinen uden om forbindelsen, fordi en fejl her fjerner din egen fjernadgang i stedet for blot at ødelægge en browserfane.

Markér den socket, der bærer konvolutten

Klientkonfigurationen får et mærke til sine krypterede udgående pakker og holder op med selv at installere ruter, så erstatningspolitikken er det eneste, der bestemmer vejene:

mark 42
route-noexec
disable-dco

Decimal 42 er hexadecimal 0x2a, og det er hexformen, som rutereglerne matcher. Referencen for link-options beskriver mark som noget, der gælder krypterede udgående pakker på Linux, hvilket netop er den socket, hvis vej du skal styre. At slå data-kanal-offload fra holder dette eksempel på userspace-vejen, hvor mærkeadfærden er den, der beskrives.

route-noexec undertrykker OpenVPNs automatiske tilføjelse og fjernelse af ruter. Det installerer intet i deres sted, så fra dette øjeblik skal ruteejeren vedligeholde hver rute, som tunnelen har brug for. Hvis en privat destination forsvinder efter ændringen, er det den manglende erstatningspolitik og ikke en fejl i mærket.

Behold ikke en værtsrute i hovedtabellen til 198.51.100.25, mens du gør dette. En sådan rute genindfører netop den undtagelse, som designet forsøger at indsnævre, og den vil vinde for HTTPS-flowet, før nogen af politikkerne nedenfor bliver konsulteret.

Send alt andet til tunneltabellen

Når tunnelinterfacet findes og har sin adresse, ser politikken sådan ud:

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ørste regel holder værtens specifikke ruter synlige, inklusive ethvert godkendt lokalt netværk, mens den gør hovedtabellens standardrute usynlig for dette opslag. Den forskel betyder noget: at undertrykke standarden er ikke det samme som at ignorere tabellen, og de lokale undtagelser, du stadig har brug for, overlever på grund af den. Læs de undtagelser en for en i stedet for at antage, at resultatet er en universel afbryder.

Umarkeret trafik falder derefter til tunneltabellen, henter tunnelkilden og forlader systemet via VPN. Markeret trafik fejler fwmark-testen på de næste to regler og fortsætter til det almindelige hovedopslag længere nede på listen, hvor uplink-standardruten stadig ligger. Den afsluttende unreachable-regel er det, der forhindrer en umarkeret flow i stille at falde tilbage til uplink'en, når tunnelruten mangler. Vælgeren er mærket fra begyndelse til slutning, og destinationsadressen indgår aldrig i beslutningen.

Behold den vagt på plads gennem afbrydelser, og installér den sammen med resten af politikken i stedet for i hånden. En regel, der forsvinder sammen med interfacet, er ikke en politik, det er et tilfælde. At slette politikken, når tunnelen falder, ændrer fejltilstanden fra “blokeret” til “lækket”, og en forældet tunnelrute, der senere timer ud, er et meget lettere problem at forklare end trafik, der forlod systemet via det forkerte interface.

Lad returvejen se det samme mærke

Udgående mærker er kun halvdelen af mekanismen, og det er den del, som de fleste gengivelser udelader. Svar på den krypterede session ankommer på uplink'en og er underlagt reverse-path-validering, som spørger, om kilden ville rutte tilbage samme vej, som den kom. Uden hjælp anvender det opslag din umarkerede tunnelpolitik og konkluderer, at pakken er på det forkerte interface.

Rettelsen tilhører firewall-ejeren: gem mærket på den udgående forbindelse, genskab det på matchende indgående pakker, og aktivér kildevalideret mærkehåndtering for den relevante vej. At OpenVPN sætter et socketmærke gør ingen af de tre ting, og en opskrift, der kun lister klientindstillingerne, er ufuldstændig. Bed om den integration skriftligt, fordi det er den mindst synlige del af designet og den letteste at tabe i en genopbygning.

Løs reverse-path-kontrol er heller ikke en erstatning. Løs tilstand kræver stadig, at der findes en rute for kilden, og den unreachable-vagt, du tilføjede, fjerner bevidst en for umarkerede opslag. Få mærkeintegrationen færdig og gennemgået, før du stoler på dette design, og behandl værtsfiltre som et separat spørgsmål: et mærke er et rutingsignal, ikke en tilladelse. Hvis integrationen mangler, er symptomet en session, der etableres og derefter bliver stille, så snart svarene begynder at ankomme.

Bevis det med to ruteopslag

Sammenlign, hvad kernen beslutter for de to kontekster, og læs dev- og src-felterne i stedet for exitstatus:

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

Det første opslag bør føre til tun1 med tunnelkilden, og det andet til uplink'en. Det er syntetiske opslag, så de beviser politikken og ikke den kørende proces: bekræft den kørende klients faktiske transportvej separat, og lav derefter en rigtig HTTPS-anmodning med certifikatverifikation slået til.

Skriv ned, hvad designet ikke dækker, før du erklærer det færdigt. DNS, IPv6 og reglernes livscyklus kræver hver deres beslutning, og dette er et IPv4-ruteeksempel snarere end en fuldstændig privatlivskonfiguration. Dets værdi er vælgeren: konvolutten får uplink-undtagelsen, og en almindelig tjeneste på samme adresse behøver ikke arve den.