Iruta ang isang Linux account sa OpenVPN gamit ang UID rule

Ang routing na nakabatay sa account ay angkop kapag bawat IPv4 socket na pag-aari ng isang Linux user ay dapat lumabas sa umiiral na tunnel, at hindi ito angkop kapag kailangan mo ng paghihiwalay sa antas ng programa. Pumipili ito ayon sa UID, kaya lahat ng tumatakbo sa ilalim ng account na iyon ay sakop, kasama ang batch job na nakalimutan mo. Ayusin ang tanong na iyon bago mo hawakan ang isang ip rule.

Ipinapalagay ng halimbawang nasa ibaba ang isang nakalaang browser account sa UID 1500, isang tunnel device na tun-office na may lokal na address na 10.80.0.11, at isang VPN na pumapayag sa mga destinasyong tinutukoy. Ang daemon mismo ay tumatakbo sa labas ng UID na iyon.

Tatlong kundisyon na pumipili ng mekanismo

Pumili ng UID rule kapag ang pagkakakilanlang gumagawa ng trabaho ay ang account, kapag katanggap-tanggap na ilipat ang lahat ng trapiko nito, at kapag ang namespace ay magiging mabigat kaysa nararapat sa gawain. Pumili ng network namespace kapag kailangan ng workload ang sarili nitong mga interface, resolver at routing table. Pumili ng proxy o binding kada proseso kapag eksaktong isang application ang dapat ilipat habang ang natitirang bahagi ng session ay nananatili sa lokal na landas. Ang pagsulat ng tatlong ito ay pumipigil sa isang rule na tahimik na sumasaklaw ng higit sa nilayon.

Ang pagkakamaling dapat iwasan ay ang ipagpalagay na ang launcher ang nagtatakda ng may-ari. Ang browser na binigyan ng URL ng session ng ibang user ay hindi gumawa ng mga socket sa ilalim ng UID 1500, at walang rule ang maglilipat ng trapikong nililikha nito.

Ang table, ang rule at ang bantay

Matapos suriin ang umiiral na mga rule at pumili ng hindi pa nagagamit na numero ng table at priority, maikli ang kaayusan: isang default route sa nakalaang table na may dalang source address ng tunnel, isang rule na nagpapadala ng lookups ng account sa table na iyon, at isang panghuling rule na humaharang sa fallback. Kapag isinulat, iyon ay idempotent na pagpapalit ng ruta, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, na sinusundan ng ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Ang bantay ay ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, at mas mahalaga ito kaysa sa ipinahihiwatig ng haba nito. Kung wala ito, ang nawawalang ruta sa table 51820 ay bumabagsak sa karaniwang uplink at tahimik na tumutulo ang account ng trapikong dapat hulihin ng patakaran. Kung mayroon ito, ang parehong pagkabigo ay nagiging timeout, ibig sabihin pagharang kaysa fallback.

Panatilihin ang normal na local address rule sa harap ng mga ito, at sadyang magpasya kung ang mga pagbubukod sa LAN o pamamahala ay nauuna sa napiling table. Ang default route na matatagpuan doon ay hindi nagtatanong sa main mamaya para sa mas tiyak na LAN route, na nakakagulat sa mga umaasang nalalapat ang pinakamahabang prefix match sa pagitan ng mga table. Isulat ang nilalayong listahan ng pagbubukod sa tala ng pagbabago habang sariwa pa ang pangangatwiran.

Ang iniiwan ng UID routing: DNS

Binubuksan ng resolver daemon ang mga upstream socket nito sa ilalim ng sarili nitong UID, kaya ang pagpili ng 1500 ay hindi naglilipat ng mga query na iyon sa table 51820. Ang pagsasama ng DNS ay hiwalay na pasya: ituro ang account sa isang resolver na maabot sa pamamagitan ng tunnel, o tanggapin na ang resolusyon ng pangalan ay sumusunod sa landas ng host habang ang trapiko ay hindi.

Ang loopback query sa lokal na stub ay hindi patunay na ginamit ng upstream query ang ruta ng browser, at ang matagumpay na pag-load ng pahina mula sa cache ay hindi rin.

Ang IPv6 ay nangangailangan ng sarili nitong pangungusap sa disenyo

Ang mga rule sa itaas ay sumasaklaw lamang sa IPv4. Kung ang pangangailangan ay isang IPv4 tunnel na walang direktang IPv6 mula sa account na ito, magdagdag ng nasuring panghuling rule tulad ng ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, pagkatapos suriin ang mga naunang IPv6 rule at ang mga pagbubukod sa loopback na nais mong panatilihin.

Ang pagharang sa direktang IPv6 ay hindi dual-stack tunneling; ito ay isang hangganan. Ang pagtawag dito na tunneling ay malilito ang susunod na taong magbabasa ng patakaran, at ang kalituhan ay lalabas bilang helpdesk ticket tungkol sa sirang IPv6 site.

I-verify gamit ang tunay na account, pagkatapos panagutan ang lifecycle

Ihambing ang mga lookup: ip -4 route get 198.51.100.25 uid 1500 laban sa parehong destinasyon gamit ang ordinaryong UID. Pagkatapos gumawa ng pinahihintulutang kahilingan sa ilalim ng nakalaang account at suriin ang source address na nakikita ng malayong dulo. Ang ginustong source address ay hindi source NAT, at hindi nito malalampasan ang isang application na nagbubuklod ng ibang bagay. Kung ang dalawang lookup ay nagbabalik ng parehong landas, hindi ginagawa ng rule ang inaakala mo.

Panatilihin ang table, mga rule at tagal ng ruta ng tunnel sa ilalim ng isang may-ari, subukan ang muling pagkonekta at pagkawala ng tunnel, at kapag inaalis ang patakaran ay tanggalin lamang ang eksaktong mga entry nito. Ang namespace ay magagamit pa rin kung hiwalay na interface at hiwalay na estado ang talagang kailangan mo.