Samme server-IP, to veier: markere OpenVPNs ytre flyt

Den vanlige løkkebeskyttelsen er en vertsrute: send trafikk til VPN-serverens offentlige adresse ut over uplink-en, slik at den krypterte økten aldri havner i sin egen tunnel. Det fungerer helt til det øyeblikket du også vil nå en webtjeneste på samme server gjennom tunnelen, fordi unntaket er knyttet til destinasjonen, og destinasjonen er identisk. Veien ut er å slutte å klassifisere etter destinasjon og i stedet klassifisere etter hvilken socket som sendte pakken.

Start med de to flytene du vil skille

Den ene flyten er den krypterte OpenVPN-transporten selv, som må forlate verten via uplink-en, ellers ville tunnelen bære sin egen ytre forbindelse. Den andre er en vanlig HTTPS-forespørsel til samme offentlige adresse, som du vil ha inne i tunnelen slik at den kommer til tjenesten fra en tunnelkilde. Samme destinasjon, i mange tilfeller samme portnummer, ulik påkrevd vei.

I denne gjennomgangen antar vi en klient på 10.90.0.10 over tun1, en offentlig serveradresse på 198.51.100.25 og en urørt hovedtabell der standarden peker på den vanlige uplink-en. Serversiden må også godta webtjenesten på den indre veien og sende trafikk tilbake til tunnelkilden; å sende en pakke til en offentlig adresse overstyrer ikke serverens lytter eller brannmurregler.

Før du endrer noe, ta vare på vertens nåværende regler og velg verdier som ingen andre bruker: en markering, et tabellnummer og tre regelprioriteter. Hold en vei tilbake inn i maskinen som ikke går over denne forbindelsen, fordi en feil her fjerner din egen fjernadgang i stedet for bare å ødelegge en nettleserfane.

Merk socketen som bærer konvolutten

Klientkonfigurasjonen får en markering for sine krypterte utgående pakker og slutter å installere ruter selv, slik at erstatningspolicyen er det eneste som bestemmer veiene:

mark 42
route-noexec
disable-dco

Desimal 42 er heksadesimal 0x2a, og det er heksformen rutereglene matcher. Referansen for link-options beskriver mark som noe som gjelder krypterte utgående pakker på Linux, som er nettopp socketen hvis vei du må styre. Å slå av datakanalens offload holder dette eksempelet på userspace-veien, der markeringsatferden er den som beskrives.

route-noexec undertrykker OpenVPNs automatiske tillegg og fjerning av ruter. Det installerer ingenting i deres sted, så fra dette øyeblikket må ruteeieren vedlikeholde hver rute tunnelen trenger. Hvis en privat destinasjon forsvinner etter endringen, er det den manglende erstatningspolicyen, ikke en feil i markeringen.

Ikke behold en vertsrute i hovedtabellen for 198.51.100.25 mens du gjør dette. En slik rute gjeninnfører nøyaktig det unntaket designet prøver å snevre inn, og den vil vinne for HTTPS-flyten før noen av policyene nedenfor blir spurt.

Send alt annet til tunneltabellen

Når tunnelgrensesnittet finnes og har adressen sin, ser policyen slik ut:

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 regelen holder vertens spesifikke ruter synlige, inkludert et eventuelt godkjent lokalt nettverk, mens den gjør hovedtabellens standardrute usynlig for dette oppslaget. Den forskjellen betyr noe: å undertrykke standarden er ikke det samme som å ignorere tabellen, og de lokale unntakene du fortsatt trenger, overlever nettopp derfor. Les unntakene ett for ett i stedet for å anta at resultatet er en universell nødstopp.

Umarkert trafikk faller da til tunneltabellen, tar tunnelkilden og forlater verten via VPN. Markert trafikk feiler fwmark-testen på de to neste reglene og fortsetter til det vanlige hovedoppslaget lenger ned i listen, der uplink-standardruten fortsatt ligger. Den avsluttende unreachable-regelen er det som hindrer en umarkert flyt i å falle stille tilbake til uplink-en når tunnelruten mangler. Velgeren er markeringen fra start til slutt, og destinasjonsadressen inngår aldri i beslutningen.

Hold den sperren på plass gjennom frakoblinger, og installer den sammen med resten av policyen i stedet for for hånd. En regel som forsvinner med grensesnittet, er ikke en policy, det er en tilfeldighet. Å slette policyen når tunnelen faller, endrer feilmodusen fra «blokkert» til «lekket», og en utdatert tunnelrute som senere løper ut, er et mye lettere problem å forklare enn trafikk som gikk ut via feil grensesnitt.

La returveien se samme markering

Utgående markeringer er bare halve mekanismen, og dette er delen de fleste gjenskapninger utelater. Svar på den krypterte økten ankommer på uplink-en og er underlagt reverse-path-validering, som spør om kilden ville rutet tilbake samme vei som den kom. Uten hjelp bruker det oppslaget din umarkerte tunnelpolicy og konkluderer med at pakken er på feil grensesnitt.

Rettelsen tilhører brannmureieren: lagre markeringen på den utgående forbindelsen, gjenopprett den på samsvarende inngående pakker og aktiver kildevalidert markeringshåndtering for den aktuelle veien. At OpenVPN setter en socketmarkering, gjør ingen av de tre tingene, og en oppskrift som bare lister klientalternativene, er ufullstendig. Be om den integrasjonen skriftlig, fordi den er den minst synlige delen av designet og den letteste å miste i en gjenoppbygging.

Løs reverse-path-kontroll er heller ikke en erstatning. Løs modus trenger fortsatt en rute for kilden, og unreachable-sperren du la til, fjerner bevisst en for umarkerte oppslag. Få markeringsintegrasjonen ferdig og gjennomgått før du stoler på dette designet, og behandle vertsfiltre som et eget spørsmål: en markering er et rutingsignal, ikke en tillatelse. Mangler integrasjonen, er symptomet en økt som etableres og deretter blir stille så snart svar begynner å ankomme.

Bevis det med to ruteoppslag

Sammenlign hva kjernen bestemmer for de to kontekstene, og les feltene dev og src 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 oppslaget bør føre til tun1 med tunnelkilden, og det andre til uplink-en. Det er syntetiske oppslag, så de beviser policyen og ikke den kjørende prosessen: bekreft den kjørende klientens faktiske transportvei separat, og lag deretter en ekte HTTPS-forespørsel med sertifikatverifisering på.

Skriv ned hva designet ikke dekker før du erklærer det ferdig. DNS, IPv6 og reglenes livssyklus trenger hver sin beslutning, og dette er et IPv4-ruteeksempel snarere enn en fullstendig personvernkonfigurasjon. Verdien er velgeren: konvolutten får uplink-unntaket, og en vanlig tjeneste på samme adresse trenger ikke arve det.