Itselde server-IP, twa paden: de bûtenste stream fan OpenVPN markearje

De gewoane lusbeskerming is in hostrûte: stjoer ferkear nei it iepenbiere adres fan de VPN-tsjinner oer de uplink nei bûten, sadat de fersifere sesje nea yn syn eigen tunnel bedarret. Dat wurket krekt oant it momint dat jo ek in websjinst op deselde tsjinner fia de tunnel berikke wolle, want de frijstelling is oan de bestimming bûn en de bestimming is identyk. De útwei is ophâlde mei klassifisearjen op bestimming en ynstee klassifisearje op hokker socket it pakket stjoerd hat.

Begjin mei de twa streams dy't jo skiede wolle

De iene stream is it fersifere OpenVPN-ferfier sels, dat oer de uplink nei bûten moat, oars soe de tunnel syn eigen bûtenste ferbining drage. De oare is in gewoan HTTPS-fersyk oan itselde iepenbiere adres, dat jo yn de tunnel hawwe wolle sadat it by de tsjinst oankomt fan in tunnelboarne. Deselde bestimming, yn in protte gefallen itselde poartnûmer, in oar fereasket paad.

Yn dizze trochrint geane wy út fan in klant op 10.90.0.10 oer tun1, in iepenbier tsjinneradres fan 198.51.100.25 en in ûnoanroerde haadtabel wêrfan't de standert nei de gewoane uplink wiist. De tsjinnerkant moat de websjinst ek op it binnenste paad akseptearje en ferkear weromstjoere nei de tunnelboarne; in pakket nei in iepenbier adres stjoere oerset de listener of it firewallbelied fan 'e tsjinner net.

Foardat jo wat feroarje, lizze jo de hjoeddeiske regels fan 'e host fêst en kieswearden dy't nimmen oars brûkt: in mark, in tabelnûmer en trije regelprioriteiten. Hâld in tagong werom yn 'e masine iepen dy't net oer dizze ferbining rint, want in flater hjir hellet jo eigen ôfstânsferbining wei ynstee fan allinnich in browser-tab te brekken.

Markearje de socket dy't it omhulse draacht

De klantkonfiguraasje krijt in mark foar syn fersifere útgeande pakketten en hâldt op sels rûtes te ynstallearjen, sadat it ferfangingsbelied it iennichste is dat paden bepaalt:

mark 42
route-noexec
disable-dco

Desimaal 42 is heksadesimaal 0x2a, en dat is de heksfoarm dêr't de rûteringsregels op passe. De referinsje foar link-options beskriuwt mark as iets dat jildt foar fersifere útgeande pakketten op Linux, krekt de socket wêrfan't jo it paad beheare moatte. It útskeakeljen fan 'e datakanaal-offload hâldt dit foarbyld op it userspace-paad, dêr't it markgedrach it gedrach is dat beskreaun wurdt.

route-noexec ûnderdrukt it automatysk tafoegjen en fuortheljen fan rûtes troch OpenVPN. It set dêr neat foar yn 't plak, dus fan dit momint ôf moat de rûte-eigner elke rûte ûnderhâlde dy't de tunnel nedich hat. As in privee bestimming nei de feroaring ferdwynt, is dat it ûntbrekkende ferfangingsbelied en net in flater yn 'e mark.

Hâld gjin hostrûte yn 'e haadtabel foar 198.51.100.25 oan wylst jo dit dogge. Sa'n rûte yntrodusearret krekt de frijstelling dy't it ûntwerp besiket te ferneauen, en hy wint foar de HTTPS-stream foardat ien fan 'e beliedsregels hjirûnder frege wurdt.

Stjoer al it oare nei de tunneltabel

Sadree't de tunnelinterface bestiet en syn adres hat, sjocht it belied der sa út:

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

De earste regel hâldt de spesifike rûtes fan 'e host sichtber, ynklusyf in goedkard lokaal netwurk, wylst er de standertrûte fan 'e haadtabel ûnsichtber makket foar dit opsykjen. Dat ferskil is wichtich: de standert ûnderdrukke is net itselde as de tabel negearje, en de lokale útsûnderingen dy't jo noch nedich hawwe, oerlibje krekt dêrtroch. Lês dy útsûnderingen ien foar ien ynstee fan oan te nimmen dat it resultaat in universele needstop is.

Net-markearre ferkear falt dan nei de tunneltabel, nimt de tunnelboarne oer en ferlit de host fia de VPN. Markearre ferkear mist de fwmark-test op 'e folgjende twa regels en giet troch nei it gewoane haadopsykjen fierderop yn 'e list, dêr't de uplink-standert noch stiet. De ôfslutende unreachable-regel is wat foarkomt dat in net-markearre stream stil weromfalt op 'e uplink as de tunnelrûte ûntbrekt. De selektor is fan begjin oant ein de mark, en it bestimmingsadres komt nea yn 'e beslissing.

Hâld dy bewekking oer ferbinings hinne oan, en ynstallearje him tegearre mei de rest fan it belied ynstee fan mei de hân. In regel dy't mei de interface ferdwynt, is gjin belied mar in tafal. It belied wiskje as de tunnel falt, feroaret de flatermodus fan “blokkearre” nei “lekt”, en in ferâldere tunnelrûte dy't letter ferfalt, is in folle makliker út te lizzen probleem as ferkear dat fia de ferkearde interface nei bûten gie.

Lit it werompaad deselde mark sjen

Utgeande marks binne mar de helte fan it meganisme, en dit is it part dat de measte reproduksjes weilitte. Antwurden op 'e fersifere sesje komme binnen fia de uplink en binne ûnderwurpen oan reverse-path-falidaasje, dy't freget oft de boarne deselde wei werom routet wurde soe. Sûnder help past dat opsykjen jo net-markearre tunnelbelied ta en konkludearret dat it pakket op 'e ferkearde interface sit.

De ferbettering heart by de firewall-eigner: bewarje de mark op 'e útgeande ferbining, restaurearje him op oerienkommende ynkommende pakketten en skeakel boarne-falidearre markôfhanneling yn foar it oanbelangjende paad. Dat OpenVPN in socketmark set, docht gjin fan dy trije dingen, en in resept dat allinnich de klantopsjes neamt, is ûnfolslein. Freegje dy yntegraasje skriftlik oan, want it is it minst sichtbere part fan it ûntwerp en it maklikst te ferliezen by in werbou.

Ek losse reverse-path-kontrôle is gjin ferfanging. Losse modus hat noch altyd in rûte nedich foar de boarne, en de unreachable-beweitsje dy't jo tafoege hawwe, hellet der bewust ien wei foar net-markearre opsykjes. Lit de yntegraasje fan 'e ferbiningsmark klear wêze en beoardiele foardat jo op dit ûntwerp fertrouwe, en behannelje hostfilters as in aparte fraach: in mark is in rûteringssinjaal, gjin tastimming. As de yntegraasje ûntbrekt, is it symptoom in sesje dy't ta stân komt en dan stil wurdt sadree't antwurden begjinne te kommen.

Bewiis it mei twa rûte-opsykjes

Fergelykje wat de kernel foar de twa konteksten beslút, en lês de fjilden dev en src ynstee fan 'e exitstatus:

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

It earste opsykjen soe nei tun1 mei de tunnelboarne liede moatte, en it twadde nei de uplink. Dat binne syntetyske opsykjes, dus se bewiize it belied en net it rinnende proses: befêstigje it wirkelikke ferfierpaad fan 'e rinnende klant apart en doch dan in echt HTTPS-fersyk mei sertifikaatferifikaasje oan.

Skriuw op wat it ûntwerp net dekt foardat jo it klear ferklearje. DNS, IPv6 en de libbenssyklus fan 'e regels hawwe elk har eigen beslissing nedich, en dit is in IPv4-rûteringsfoarbyld ynstee fan in folsleine privacykonfiguraasje. De wearde is de selektor: it omhulse krijt de uplink-frijstelling, en in gewoane tsjinst op itselde adres hoecht dy net te ervjen.