Yhden Linux-tilin reititys OpenVPN:n läpi UID-säännöllä

Tilikohtainen reititys sopii, kun jokaisen yhden Linux-käyttäjän omistaman IPv4-soketin pitää lähteä olemassa olevan tunnelin kautta, eikä se sovi, kun tarvitset eristystä ohjelmatasolla. Se valitsee UID:n mukaan, joten kaikki kyseisellä tilillä ajettava kuuluu piiriin, mukaan lukien eräajo, jonka unohdit. Ratkaise tämä kysymys ennen kuin kosket yhteenkään ip rule.

Alla oleva esimerkki olettaa UID 1500:ssa olevan erillisen selaintilin, paikallisen osoitteen 10.80.0.11 omaavan tunnelilaitteen tun-office ja VPN:n, joka sallii kyseiset kohteet. Itse daemon toimii tämän UID:n ulkopuolella.

Kolme ehtoa, jotka valitsevat mekanismin

Valitse UID-sääntö, kun työn tekevä identiteetti on tili, kun koko sen liikenteen siirtäminen on hyväksyttävää ja kun namespace olisi raskaampi kuin tehtävä ansaitsee. Valitse verkon namespace, kun työkuorma tarvitsee omat rajapinnat, resolverin ja reititystaulun. Valitse välityspalvelin tai prosessikohtainen sidonta kun täsmälleen yhden sovelluksen pitää siirtyä samalla kun istunnon loppuosa pysyy paikallisella polulla. Näiden kolmen kirjaaminen estää säännön, joka kattaa hiljaa enemmän kuin oli tarkoitus.

Vältettävä virhe on olettaa, että käynnistäjä määrittää omistajan. Selain, jolle toisen käyttäjän istunto antoi URL:n, ei ole luonut soketteja UID 1500:n alla, eikä mikään sääntö siirrä sen tuottamaa liikennettä.

Taulu, sääntö ja vartija

Kun olemassa olevat säännöt on tarkistettu ja käyttämättömät taulu- ja prioriteettinumerot valittu, järjestely on lyhyt: oletusreitti omistetussa taulussa, joka kantaa tunnelin lähdeosoitetta, sääntö joka lähettää tilin haut siihen tauluun, ja päättävä sääntö, joka estää varareitin. Kirjoitettuna se on idempotentti reitin korvaus, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, jota seuraa ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Vartija on ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, ja se merkitsee enemmän kuin pituutensa antaa ymmärtää. Ilman sitä taulusta 51820 puuttuva reitti putoaa tavalliselle ylälinkille ja tili vuotaa hiljaa liikennettä, joka käytännön piti napata. Sen kanssa sama vika muuttuu aikakatkaisuksi eli estoksi varareitin sijaan.

Pidä tavallinen paikallisen osoitteen sääntö näiden edellä ja päätä tietoisesti, kuuluvatko LAN- tai hallintapoikkeukset valitun taulun eteen. Sieltä löytyvä oletusreitti ei kysy myöhemmin main-taulukosta tarkempaa LAN-reittiä, mikä yllättää ne, jotka odottavat pisimmän etuliitteen täsmäytyksen pätevän taulujen välillä. Kirjoita aiottu poikkeusluettelo muutoksen muistiin, kun perustelu on vielä tuore.

Mitä UID-reititys jättää pois: DNS

Resolver-daemon avaa ylävirran sokettinsa oman UID:nsä alla, joten 1500:n valinta ei siirrä näitä kyselyitä tauluun 51820. DNS-integraatio on erillinen päätös: ohjaa tili tunneliin kautta tavoitettavaan resolveriin tai hyväksy, että nimenselvitys seuraa isännän polkua mutta liikenne ei.

Loopback-kysely paikalliselle stubille ei ole todiste siitä, että ylävirran kysely käytti selaimen reittiä, eikä sitä ole onnistunut sivun lataus välimuistista.

IPv6 tarvitsee oman lauseensa suunnitteluun

Yllä olevat säännöt kattavat vain IPv4:n. Jos vaatimus on IPv4-tunneli ilman suoraa IPv6:ta tältä tililtä, lisää tarkistettu päättävä sääntö kuten ip -6 rule add priority 12101 uidrange 1500-1500 unreachable ja tarkista sitten aiemmat IPv6-säännöt sekä loopback-poikkeukset, jotka haluat säilyttää.

Suoran IPv6:n estäminen ei ole kaksoispino-tunnelointia; se on raja. Sen kutsuminen tunneloinniksi hämmentää seuraavaa käytännön lukijaa, ja hämmennys nousee tukipyyntönä rikkinäisestä IPv6-sivustosta.

Tarkista oikealla tilillä ja ota sitten elinkaari haltuusi

Vertaa hakuja: ip -4 route get 198.51.100.25 uid 1500 samaan kohteeseen tavallisella UID:llä. Tee sitten sallittu pyyntö omistetulla tilillä ja tarkista lähdeosoite, jonka kaukopää näkee. Ensisijainen lähdeosoite ei ole source NAT, eikä se ohita sovellusta, joka sitoo jotain muuta. Jos molemmat haut palauttavat saman polun, sääntö ei tee sitä mitä luulet.

Pidä taulu, säännöt ja tunnelireitin elinikä yhdellä omistajalla, testaa uudelleenyhdistäminen ja tunnelin menetys, ja poista käytännön poistuessa vain sen täsmälliset merkinnät. Namespace on yhä saatavilla, jos erilliset rajapinnat ja erillinen tila ovat se, mitä todella tarvitset.