Dieselfde bediener-IP, twee paaie: die buitenste vloei van OpenVPN gemerk

Die gewone lusbeskerming is 'n hostroete: stuur verkeer vir die VPN-bediener se publieke adres deur die uplink uit sodat die versleutelde sessie nooit in sy eie tonnel beland nie. Dit werk presies tot die oomblik wanneer jy ook 'n webdiens op dieselfde bediener deur die tonnel wil bereik, want die vrystelling is op die bestemming gesleutel en die bestemming is identies. Die uitweg is om op te hou om volgens bestemming te klassifiseer en eerder te klassifiseer volgens watter socket die pakkie gestuur het.

Begin by die twee vloeie wat jy wil skei

Die een vloei is die versleutelde OpenVPN-vervoer self, wat deur die uplink moet vertrek, anders sou die tonnel sy eie buitenste verbinding dra. Die ander is 'n gewone HTTPS-versoek na dieselfde publieke adres, wat jy in die tonnel wil hê sodat dit by die diens aankom vanaf 'n tonnelbron. Dieselfde bestemming, in baie gevalle dieselfde poortnommer, maar 'n ander vereiste pad.

Vir hierdie deurloop, neem aan 'n kliënt op 10.90.0.10 oor tun1, 'n bediener se publieke adres van 198.51.100.25, en 'n ongeraakte hoof-tabel wie se verstek na die gewone uplink wys. Die bedienerkant moet ook die webdiens op die binnepad aanvaar en verkeer na die tonnelbron terugstuur; om 'n pakkie na 'n publieke adres te stuur, oorheers nie die bediener se luisteraar of firewall-beleid nie.

Voordat jy iets verander, teken die gasheer se huidige reëls op en kies waardes wat niemand anders gebruik nie: 'n merk, 'n tabelnommer en drie reëlprioriteite. Hou 'n weg buite die verbinding terug na die masjien oop, want 'n fout hier verwyder jou eie afstandtoegang eerder as om net 'n blaaier-oortjie te breek.

Merk die socket wat die omhulsel dra

Die kliëntkonfigurasie kry 'n merk vir sy versleutelde uitgaande pakkies, en hou op om self roetes te installeer sodat die vervangingsbeleid die enigste ding is wat paaie bepaal:

mark 42
route-noexec
disable-dco

Desimale 42 is heksadesimaal 0x2a, en dit is die heksvorm waaraan die roetereëls sal pas. Die verwysing vir skakelopsies beskryf mark as iets wat op versleutelde uitgaande pakkies op Linux toegepas word, wat presies die socket is wie se pad jy moet beheer. Om die datakanaal-oordrag te deaktiveer, hou hierdie voorbeeld op die gebruikersruimte-pad, waar die merkgedrag dié is wat beskryf word.

route-noexec onderdruk OpenVPN se outomatiese byvoeging en verwydering van roetes. Dit installeer niks in hul plek nie, so van hierdie oomblik af moet die roete-eienaar elke roete onderhou wat die tonnel nodig het. As 'n private bestemming ná die verandering verdwyn, is dit die ontbrekende vervangingsbeleid, nie 'n fout in die merk nie.

Moenie 'n hoof-tabel-hostroete vir 198.51.100.25 hou terwyl jy dit doen nie. So 'n roete bring presies die vrystelling terug wat die ontwerp probeer vernou, en dit sal vir die HTTPS-vloei wen voordat enigeen van die beleid hieronder geraadpleeg word.

Stuur alles anders na die tonneltabel

Sodra die tonnelkoppelvlak bestaan en sy adres het, lyk die beleid so:

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

Die eerste reël hou die gasheer se spesifieke roetes sigbaar, insluitend enige goedgekeurde plaaslike netwerk, terwyl dit die hoof-tabel se verstekroete onsigbaar maak vir hierdie opsoek. Daardie onderskeid maak saak: om die verstek te onderdruk is nie dieselfde as om die tabel te ignoreer nie, en die plaaslike uitsonderings wat jy nog nodig het, oorleef daardeur. Lees daardie uitsonderings een vir een eerder as om aan te neem die resultaat is 'n universele noodskakelaar.

Ongemerkte verkeer val dan na die tonneltabel, tel die tonnelbron op en vertrek deur die VPN. Gemerkte verkeer misluk die fwmark-toets op die volgende twee reëls en gaan voort na die gewone hoof-opsoek verder af in die lys, waar die uplink-verstek nog lê. Die terminerende unreachable-reël is wat keer dat 'n ongemerkte vloei stilweg na die uplink terugval wanneer die tonnelroete ontbreek. Die keurder is van begin tot end die merk, en die bestemmingsadres tree nooit tot die besluit toe nie.

Hou daardie wag in plek oor ontkoppelings heen, en installeer dit saam met die res van die beleid eerder as met die hand. 'n Reël wat saam met die koppelvlak verdwyn, is nie 'n beleid nie, dit is 'n toevalligheid. Om die beleid te skrap wanneer die tonnel val, verander die foutmodus van “geblokkeer” na “gelek”, en 'n verouderde tonnelroete wat later uitloopt, is 'n baie makliker probleem om te verduidelik as verkeer wat deur die verkeerde koppelvlak vertrek het.

Laat die terugpad dieselfde merk sien

Uitgaande merke is net die helfte van die meganisme, en dit is die deel wat die meeste reproduksies weglaat. Antwoorde op die versleutelde sessie kom op die uplink aan en is onderhewig aan terugpad-validasie, wat vra of die bron dieselfde pad terug sou roeteer. Sonder hulp pas daardie opsoek jou ongemerkte tonnelbeleid toe en kom tot die gevolgtrekking dat die pakkie op die verkeerde koppelvlak is.

Die regstelling behoort aan die firewall-eienaar: stoor die merk op die uitgaande verbinding, herstel dit op ooreenstemmende inkomende pakkies, en aktiveer bron-gevalideerde merkhantering vir die betrokke pad. Om 'n socketmerk in OpenVPN te stel, doen nie een van daardie drie dinge nie, en 'n resep wat net die kliëntopsies lys, is onvolledig. Vra daardie integrasie skriftelik, want dit is die mins sigbare deel van die ontwerp en die maklikste om in 'n herbou te verloor.

Ook losse terugpad-kontrole is nie 'n plaasvervanger nie. Los modus het steeds 'n roete vir die bron nodig, en die unreachable-wag wat jy bygevoeg het, verwyder doelbewus een vir ongemerkte opsoeke. Laat die verbinding-merk-integrasie klaar en nagesien wees voordat jy op hierdie ontwerp staatmaak, en behandel gasheerfilters as 'n aparte vraag: 'n merk is 'n roetesein, nie toestemming nie. As die integrasie ontbreek, is die simptoom 'n sessie wat tot stand kom en dan stil word sodra antwoorde begin aankom.

Bewys dit met twee roete-opsoeke

Vergelyk wat die kern vir die twee kontekste besluit, en lees die dev- en src-velde eerder as die uitgangstatus:

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

Die eerste opsoek behoort na tun1 met die tonnelbron te lei, en die tweede na die uplink. Dit is sintetiese opsoeke, so hulle bewys die beleid en nie die lewende proses nie: bevestig die lopende kliënt se werklike vervoerpad afsonderlik, en maak dan 'n regte HTTPS-versoek met sertifikaatverifikasie aan.

Skryf neer wat die ontwerp nie dek nie voordat jy dit as klaar verklaar. DNS, IPv6 en die lewensiklus van die reëls het elkeen hulle eie besluit nodig, en dit is 'n IPv4-roetevoorbeeld eerder as 'n volledige privaatheidkonfigurasie. Die waarde daarvan is die keurder: die omhulsel kry die uplink-vrystelling, en 'n gewone diens op dieselfde adres hoef dit nie te erf nie.