Rutarea unui cont Linux prin OpenVPN cu o regulă UID

Rutarea pe bază de cont se potrivește când fiecare socket IPv4 deținut de un utilizator Linux trebuie să iasă printr-un tunel existent, și nu se potrivește când aveți nevoie de izolare la nivel de program. Selectează după UID, așa că tot ce rulează sub acel cont intră în sferă, inclusiv sarcina batch pe care ați uitat-o. Rezolvați această întrebare înainte de a atinge o singură ip rule.

Exemplul de mai jos presupune un cont de browser dedicat la UID 1500, un dispozitiv de tunel tun-office cu adresa locală 10.80.0.11 și un VPN care permite destinațiile în cauză. Demonul propriu-zis rulează în afara acelui UID.

Trei condiții care aleg mecanismul

Alegeți o regulă UID când identitatea care face treaba este contul, când mutarea întregului său trafic este acceptabilă și când un namespace ar fi mai greu decât merită sarcina. Alegeți un namespace de rețea când volumul de lucru are nevoie de propriile interfețe, resolver și tabelă de rutare. Alegeți un proxy sau o legare pe proces când exact o aplicație trebuie mutată în timp ce restul sesiunii rămâne pe calea locală. Scrierea acestor trei lucruri împiedică o regulă care acoperă în tăcere mai mult decât s-a intenționat.

Greșeala de evitat este să presupuneți că lansatorul definește proprietarul. Un browser căruia sesiunea altui utilizator i-a dat un URL nu a creat socketuri sub UID 1500, iar nicio regulă nu va muta traficul pe care îl generează.

Tabela, regula și garda

După verificarea regulilor existente și alegerea unor numere de tabelă și prioritate nefolosite, aranjamentul este scurt: o rută implicită într-o tabelă dedicată care poartă adresa sursă a tunelului, o regulă care trimite căutările contului în acea tabelă și o regulă finală care blochează calea de rezervă. Scris, aceasta este o înlocuire idempotentă de rută, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, urmată de ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Garda este ip -4 rule add priority 12101 uidrange 1500-1500 unreachable și contează mai mult decât sugerează lungimea ei. Fără ea, o rută lipsă din tabela 51820 cade pe legătura superioară obișnuită și contul scurge în tăcere traficul pe care politica trebuia să îl prindă. Cu ea, aceeași defecțiune devine un timp de așteptare, adică blocare în loc de rezervă.

Țineți regula normală a adresei locale înaintea acestora și decideți conștient dacă excepțiile LAN sau de administrare vin înaintea tabelei alese. O rută implicită găsită acolo nu întreabă mai târziu main pentru o rută LAN mai specifică, ceea ce îi surprinde pe cei care se așteaptă ca potrivirea celui mai lung prefix să se aplice între tabele. Scrieți lista de excepții dorită în nota de modificare cât timp raționamentul este încă proaspăt.

Ce lasă deoparte rutarea UID: DNS

Demonul resolver deschide socketurile sale superioare sub propriul UID, așa că selectarea 1500 nu mută acele interogări în tabela 51820. Integrarea DNS este o decizie separată: îndreptați contul către un resolver accesibil prin tunel sau acceptați că rezolvarea numelor urmează calea gazdei, iar traficul nu.

O interogare prin loopback către un stub local nu este dovada că interogarea superioară a folosit ruta browserului, iar o încărcare reușită a paginii din cache nici atât.

IPv6 are nevoie de propria propoziție în proiect

Regulile de mai sus acoperă doar IPv4. Dacă cerința este un tunel IPv4 fără IPv6 direct din acest cont, adăugați o regulă finală revizuită precum ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, apoi verificați regulile IPv6 anterioare plus excepțiile loopback pe care vreți să le păstrați.

Blocarea IPv6 direct nu este tunelare cu două stive; este o graniță. Să o numiți tunelare va deruta următoarea persoană care citește politica, iar confuzia va apărea ca un tichet de asistență despre un site IPv6 stricat.

Verificați cu contul real, apoi asumați-vă ciclul de viață

Comparați căutările: ip -4 route get 198.51.100.25 uid 1500 față de aceeași destinație cu un UID obișnuit. Apoi faceți o cerere permisă sub contul dedicat și verificați adresa sursă pe care o vede capătul îndepărtat. O adresă sursă preferată nu este source NAT și nu va suprascrie o aplicație care leagă altceva. Dacă ambele căutări returnează aceeași cale, regula nu face ce credeți.

Țineți tabela, regulile și durata de viață a rutei tunelului sub un singur proprietar, testați o reconectare și o pierdere a tunelului, iar la retragerea politicii eliminați doar intrările ei exacte. Un namespace este încă disponibil dacă interfețe separate și stare separată sunt ceea ce aveți cu adevărat nevoie.