Sama palvelimen IP, kaksi polkua: OpenVPN:n ulkoisen virran merkitseminen

Tavallinen silmukkasuojaus on isäntäreitti: lähetä liikenne VPN-palvelimen julkiseen osoitteeseen uplinkin kautta, jotta salattu istunto ei koskaan päädy omaan tunneliinsa. Tämä toimii täsmälleen siihen hetkeen asti, kun haluat tavoittaa tunnelin kautta myös samalla palvelimella olevan verkkopalvelun, koska vapautus on sidottu kohteeseen ja kohde on sama. Ulospääsy on lopettaa kohteen mukaan luokittelu ja alkaa luokitella sen mukaan, mikä pesä paketin lähetti.

Aloita kahdesta virrasta, jotka haluat erottaa

Toinen virta on salattu OpenVPN-siirto itse, jonka on poistuttava uplinkin kautta, muuten tunneli kantaisi oman ulkoisen yhteytensä. Toinen on tavallinen HTTPS-pyyntö samaan julkiseen osoitteeseen, jonka haluat tunnelin sisään, jotta se saapuu palveluun tunnelin lähteestä. Sama kohde, monissa tapauksissa sama porttinumero, eri vaadittu polku.

Oletetaan tässä läpikäynnissä asiakas osoitteessa 10.90.0.10 tunn1:n kautta, palvelimen julkinen osoite 198.51.100.25 ja koskematon päätöstaulu, jonka oletusreitti osoittaa tavalliselle uplinkille. Palvelinpuolen on myös hyväksyttävä verkkopalvelu sisäisellä polulla ja lähetettävä liikenne takaisin tunnelin lähteelle; paketin lähettäminen julkiseen osoitteeseen ei ohita palvelimen kuuntelijaa tai palomuurikäytäntöä.

Ennen kuin muutat mitään, kirjaa isännän nykyiset säännöt ja valitse arvot, joita kukaan muu ei käytä: merkki, taulun numero ja kolme säännön prioriteettia. Pidä yhteys takaisin koneeseen, joka ei kulje tämän yhteyden kautta, sillä virhe täällä poistaa oman etäkäyttösi sen sijaan, että vain rikkoisi selaimen välilehden.

Merkitse pesa, joka kantaa kirjekuoren

Asiakkaan kokoonpano saa merkin salatuille lähteville paketeilleen ja lopettaa reittien asentamisen itse, joten korvauskäytäntö on ainoa, joka määrää polut:

mark 42
route-noexec
disable-dco

Desimaali 42 on heksadesimaali 0x2a, ja juuri heksadesimaalimuotoon reitityssäännöt täsmäävät. Link-options-viite kuvaa markin koskevan salattuja lähteviä paketteja Linuxissa, eli täsmälleen sitä pesää, jonka polkua sinun on hallittava. Datakanavan purun poistaminen käytöstä pitää tämän esimerkin käyttäjätilan polulla, jossa merkin käyttäytyminen on kuvattu.

route-noexec vaimentaa OpenVPN:n automaattisen reittien lisäämisen ja poistamisen. Se ei asenna mitään niiden tilalle, joten tästä hetkestä lähtien reittien omistajan on ylläpidettävä jokaista reittiä, jota tunneli tarvitsee. Jos yksityinen kohde katoaa muutoksen jälkeen, se on puuttuva korvauskäytäntö, ei merkin vika.

Älä pidä päätöstaulussa isäntäreittiä osoitteelle 198.51.100.25 tätä tehdessäsi. Sellainen reitti tuo takaisin juuri sen vapautuksen, jota suunnittelu yrittää kaventaa, ja se voittaa HTTPS-virran osalta ennen kuin mitään alla olevista käytännöistä kysytään.

Lähetä kaikki muu tunnelitauluun

Kun tunnelin rajapinta on olemassa ja pitää osoitteensa, käytäntö näyttää tältä:

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

Ensimmäinen sääntö pitää isännän erityiset reitit näkyvinä, mukaan lukien mahdollinen hyväksytty paikallisverkko, samalla kun se tekee päätöstaulun oletusreitistä näkymättömän tälle haulle. Tämä ero on tärkeä: oletusreitin vaimentaminen ei ole sama kuin taulun huomiotta jättäminen, ja paikalliset poikkeukset, joita vielä tarvitset, säilyvät juuri siksi. Lue nuo poikkeukset yksi kerrallaan sen sijaan, että olettaisit tuloksen olevan yleinen hätäkatkaisin.

Merkitsemätön liikenne putoaa sitten tunnelitauluun, ottaa tunnelin lähteen ja poistuu VPN:n kautta. Merkitty liikenne epäonnistuu fwmark-testissä seuraavilla kahdella säännöllä ja jatkaa tavalliseen päähakuun listan alempana, jossa uplinkin oletusreitti yhä on. Lopullinen unreachable-sääntö on se, joka estää merkitsemättömän virran hiljaisen putoamisen takaisin uplinkille, kun tunnelin reitti puuttuu. Valitsin on merkki alusta loppuun, eikä kohdeosoite koskaan tule päätökseen.

Pidä tuo vartija paikallaan yhteyksien välillä ja asenna se muun käytännön mukana, ei käsin. Sääntö, joka katoaa rajapinnan mukana, ei ole käytäntö vaan sattuma. Käytännön poistaminen tunnelin pudotessa muuttaa vikatilan ”estetty”-tilasta ”vuotanut”-tilaan, ja vanhentunut tunnelireitti, joka myöhemmin vanhenee, on paljon helpompi selittää kuin väärän rajapinnan kautta lähtenyt liikenne.

Anna paluupolun nähdä sama merkki

Lähtevät merkit ovat vain puolet mekanismista, ja tämä on se osa, jonka useimmat toisinnot jättävät pois. Vastaukset salattuun istuntoon saapuvat uplinkin kautta ja ovat paluupolun validoinnin alaisia, joka kysyy, reititettäisiinkö lähde takaisin samaa polkua. Ilman apua tuo haku soveltaa merkitsevää tunnelikäytäntöäsi ja päättelee, että paketti on väärällä rajapinnalla.

Korjaus kuuluu palomuurin omistajalle: tallenna merkki lähtevälle yhteydelle, palauta se vastaaviin saapuviin paketteihin ja ota käyttöön lähteen validoima merkkien käsittely kyseiselle polulle. Se, että OpenVPN asettaa pesämerkin, ei tee mitään noista kolmesta, ja resepti, joka luettelee vain asiakkaan asetukset, on puutteellinen. Pyydä tuo integraatio kirjallisesti, koska se on suunnittelun vähiten näkyvä osa ja helpoimmin uudelleenrakennuksessa häviävä.

Eikä löysä paluupolun tarkistus ole korvike. Löysä tila vaatii silti jonkin reitin lähteelle, ja lisäämäsi unreachable-vartija poistaa sellaisen tarkoituksella merkitsemättömille hauille. Viimeistele ja katselmoi yhteyden merkin integraatio ennen kuin luotat tähän suunnitteluun, ja käsittele isäntäsuodattimia erillisenä kysymyksenä: merkki on reitityssignaali, ei lupa. Jos integraatio puuttuu, oireena on istunto, joka muodostuu ja vaikenee heti, kun vastauksia alkaa saapua.

Todista se kahdella reittihauilla

Vertaa, mitä ydin päättää kahdessa kontekstissa, ja lue dev- ja src-kentät poistumistilan sijaan:

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

Ensimmäisen haun pitäisi ratketa tunn1:een tunnelin lähteellä ja toisen uplinkille. Ne ovat synteettisiä hakuja, joten ne todistavat käytännön eivätkä käynnissä olevaa prosessia: vahvista käynnissä olevan asiakkaan todellinen siirtopolku erikseen ja tee sitten todellinen HTTPS-pyyntö sertifikaatin varmennus päällä.

Kirjaa, mitä suunnittelu ei kata, ennen kuin julistat sen valmiiksi. DNS, IPv6 ja sääntöjen elinkaari tarvitsevat kukin oman päätöksensä, ja tämä on IPv4-reititysesimerkki eikä täydellinen yksityisyysasetus. Sen arvo on valitsin: kirjekuori saa uplinkin vapautuksen, eikä tavallisen palvelun samassa osoitteessa tarvitse periä sitä.