Same tenar-IP, to vegar: merking av den ytre flyten til OpenVPN

Den vanlege løkkevernet er ei vertsrute: send trafikk til den offentlege adressa til VPN-tenaren ut over opplenkja, slik at den krypterte økta aldri hamnar i sin eigen tunnel. Det verkar heilt til det augneblinken du også vil nå ein webtente på same tenar gjennom tunnelen, fordi unntaket er knytt til destinasjonen, og destinasjonen er identisk. Vegen ut er å slutte å klassifisere etter destinasjon og i staden klassifisere etter kva socket som sende pakken.

Start med dei to flytane du vil skilje

Den eine flyten er den krypterte OpenVPN-transporten sjølv, som må forlate via opplenkja, elles ville tunnelen bere si eiga ytre tilkopling. Den andre er ein vanleg HTTPS-førespurnad til same offentlege adresse, som du vil ha inne i tunnelen slik at han kjem til tenesta frå ei tunnelkjelde. Same destinasjon, i mange tilfelle same portnummer, ulik påkravd veg.

I denne gjennomgangen føreset vi ein klient på 10.90.0.10 over tun1, ei offentleg tenaradresse på 198.51.100.25 og ein urørt hovudtabell der standarden peikar på den vanlege opplenkja. Tenarsida må også godta webtenta på den indre vegen og sende trafikk tilbake til tunnelkjelda; å sende ein pakke til ei offentleg adresse overstyrer ikkje lyttaren eller brannmurreglane til tenaren.

Før du endrar noko, ta vare på dei noverande reglane til verten og vel verdiar som ingen andre brukar: ei merking, eit tabellnummer og tre regelprioritetar. Hald ein veg tilbake inn i maskinen som ikkje går over denne tilkoplinga, fordi ein feil her fjernar din eigen fjernåtkomst i staden for berre å øydeleggje ei nettlesarfane.

Merk socketen som ber konvolutten

Klientkonfigurasjonen får ei merking for sine krypterte utgåande pakkar og sluttar å installere ruter sjølv, slik at erstatningspolicyen er det einaste som bestemmer vegane:

mark 42
route-noexec
disable-dco

Desimal 42 er heksadesimal 0x2a, og det er heksforma ruterelgane matchar. Referansen for link-options skildrar mark som noko som gjeld krypterte utgåande pakkar på Linux, som er nettopp socketen kvis veg du må styre. Å slå av datakanalens offload held dette dømet på userspace-vegen, der merkjeåtferda er den som blir skildra.

route-noexec undertrykkjer den automatiske tilleggjinga og fjerninga av ruter som OpenVPN gjer. Det installerer ingenting i staden, så frå dette augneblinken må ruteeigaren vedlikehalde kvar rute tunnelen treng. Viss ein privat destinasjon forsvinn etter endringa, er det den manglande erstatningspolicyen, ikkje ein feil i merkinga.

Ikkje hald ei vertsrute i hovudtabellen for 198.51.100.25 medan du gjer dette. Ei slik rute gjeninnfører nettopp det unntaket designet prøver å snevre inn, og ho vil vinne for HTTPS-flyten før nokon av policyane nedanfor blir spurt.

Send alt anna til tunneltabellen

Når tunnelgrensesnittet finst og har adressa si, 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 held dei spesifikke rutene til verten synlege, inkludert eit eventuelt godkjent lokalt nett, medan han gjer standardruta i hovudtabellen usynleg for dette oppslaget. Den skilnaden betyr noko: å undertrykkje standarden er ikkje det same som å ignorere tabellen, og dei lokale unntaka du framleis treng, overlever nettopp derfor. Les unntaka eitt for eitt i staden for å gå ut frå at resultatet er ein universell naudstopp.

Umerkt trafikk fell då til tunneltabellen, tar tunnelkjelda og forlèt via VPN. Merkt trafikk feilar fwmark-testen på dei to neste reglane og held fram til det vanlege hovudoppslaget lenger ned i lista, der opplenkja sin standard framleis ligg. Den avsluttande unreachable-regelen er det som hindrar ein umerkt flyt i å falle stille tilbake til opplenkja når tunnelruta manglar. Veljaren er merkinga frå start til slutt, og destinasjonsadressa inngår aldri i avgjerda.

Hald den sperra på plass gjennom fråkoplingar, og installer ho saman med resten av policyen i staden for for hand. Ein regel som forsvinn med grensesnittet, er ingen policy, det er eit samantreff. Å slette policyen når tunnelen fell, endrar feilmodusen frå «blokkert» til «leka», og ei utdatert tunnelrute som seinare løper ut, er eit mykje lettare problem å forklare enn trafikk som gjekk ut via feil grensesnitt.

La returvegen sjå same merkinga

Utgåande merkingar er berre halve mekanismen, og dette er delen dei fleste attskapingane utelèt. Svar på den krypterte økta kjem inn på opplenkja og er underlagt reverse-path-validering, som spør om kjelda ville ruta tilbake same vegen som ho kom. Utan hjelp brukar det oppslaget din umerka tunnelpolicy og konkluderer med at pakken er på feil grensesnitt.

Rettinga høyrer til brannmureigaren: lagre merkinga på den utgåande tilkoplinga, gjenopprett ho på samsvarande inngåande pakkar og slå på kjeldevalidert merkjehandtering for den aktuelle vegen. At OpenVPN set ei socketmerking, gjer ingen av dei tre tinga, og ei oppskrift som berre listar klientvala, er ufullstendig. Be om den integrasjonen skriftleg, fordi han er den minst synlege delen av designet og den lettaste å miste i ein gjenoppbygging.

Laus reverse-path-kontroll er heller ikkje nokon erstatning. Laus modus treng framleis ei rute for kjelda, og unreachable-sperra du la til, fjernar med vilje ei for umerka oppslag. Få merkjeintegrasjonen ferdig og gjennomgått før du stolar på dette designet, og handsam vertsfilter som eit eige spørsmål: ei merking er eit rutingsignal, ikkje eit løyve. Manglar integrasjonen, er symptomet ei økt som blir etablert og deretter blir stille så snart svar byrjar å kome.

Prov det med to ruteoppslag

Samanlikn kva kjernen avgjer for dei to kontekstane, og les felta dev og src i staden 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 tunnelkjelda, og det andre til opplenkja. Det er syntetiske oppslag, så dei provar policyen og ikkje den køyrande prosessen: stadfest den faktiske transportvegen til den køyrande klienten separat, og lag deretter ein ekte HTTPS-førespurnad med sertifikatverifisering på.

Skriv ned kva designet ikkje dekkjer før du erklærer det ferdig. DNS, IPv6 og livssyklusen til reglane treng kvar si avgjerd, og dette er eit IPv4-rutedøme snarare enn ein fullstendig personvernkonfigurasjon. Verdien er veljaren: konvolutten får opplenkje-unntaket, og ei vanleg teneste på same adresse treng ikkje arve det.