Een Linux-rekening deur OpenVPN lei met 'n UID-reël

Rekeninggebaseerde roetering pas wanneer elke IPv4-sok wat deur een Linux-gebruiker besit word, deur 'n bestaande tonnel moet vertrek, en dit pas nie wanneer jy isolasie op programvlak nodig het. Dit kies volgens UID, dus enigiets wat as daardie rekening loop, is in die bestek, insluitend die bondelwerk wat jy vergeet het. Bespreek daardie vraag voordat jy aan 'n enkele ip rule raak.

Die voorbeeld hieronder neem 'n toegewyde blaaierrekening by UID 1500 aan, 'n tonneltoestel tun-office met plaaslike adres 10.80.0.11, en 'n VPN wat die betrokke bestemmings toelaat. Die daemon self loop buite daardie UID.

Drie voorwaardes wat die meganisme kies

Kies 'n UID-reël wanneer die identiteit wat die werk doen die rekening is, wanneer dit aanvaarbaar is om al sy verkeer te verskuif, en wanneer 'n naamruimte swaarder sou wees as wat die taak verdien. Kies 'n netwerknaamruimte wanneer die werklading sy eie koppelvlakke, oplosser en roetetabel nodig het. Kies 'n instaanbediener of 'n binding per proses wanneer presies een toepassing moet beweeg terwyl die res van die sessie op die plaaslike pad bly. Om daardie drie neer te skryf verhoed 'n reël wat stilweg meer dek as wat bedoel is.

Die fout om te vermy is om aan te neem dat 'n beginprogram die eienaar bepaal. 'n Blaaier wat 'n URL van 'n ander gebruiker se sessie kry, het nie sokke onder UID 1500 geskep nie, en geen reël sal die verkeer wat dit genereer verskuif nie.

Die tabel, die reël en die wag

Nadat jy bestaande reëls nagegaan en ongebruikte tabel- en prioriteitsnommers gekies het, is die reëling kort: 'n verstekroete in 'n toegewyde tabel wat die tonnel se bronadres dra, 'n reël wat die rekening se opsoeke na daardie tabel stuur, en 'n beëindigende reël wat die terugval blokkeer. Uitgeskryf is dit 'n idempotente roete-vervanging, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, gevolg deur ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Die wag is ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, en dit maak meer saak as wat sy lengte suggereer. Sonder dit val 'n ontbrekende roete in tabel 51820 deur na die gewone opstuurverbinding en lek die rekening stilweg verkeer wat die beleid bedoel was om te vang. Daarmee word dieselfde fout 'n tydsverloop, wat blokkeer eerder as terugval.

Hou die normale plaaslike-adresreël voor hierdie, en besluit bewustelik of LAN- of bestuursuitsonderings voor die gekose tabel hoort. 'n Verstek wat daar gevind word, raadpleeg nie later main vir 'n meer spesifieke LAN-roete nie, wat mense verras wat verwag dat langste-voorvoegsel-passing oor tabelle heen geld. Skryf die beoogde uitsonderingslys in die veranderingsnota terwyl die redenering nog vars is.

Wat UID-roetering uitlaat: DNS

'n Oplosser-daemon maak sy opstroom-sokke onder sy eie UID oop, so om 1500 te kies skuif nie daardie navrae na tabel 51820 nie. DNS-integrasie is 'n aparte besluit: wys die rekening na 'n oplosser wat deur die tonnel bereikbaar is, of aanvaar dat naamresolusie die gasheer se pad volg terwyl verkeer dit nie doen nie.

'n Loopback-navraag na 'n plaaslike stomp is nie bewyse dat die opstroom-navraag die blaaier se roete gebruik het nie, en 'n suksesvolle bladsylading uit die kas is dit ook nie.

IPv6 het sy eie sin in die ontwerp nodig

Die reëls hierbo dek slegs IPv4. As die vereiste 'n IPv4-tonnel is met geen direkte IPv6 vanaf hierdie rekening nie, voeg 'n nagegane beëindigende reël soos ip -6 rule add priority 12101 uidrange 1500-1500 unreachable by, en kyk dan na vroeëre IPv6-reëls plus die loopback-uitsonderings wat jy wil behou.

Om direkte IPv6 te blokkeer is nie dubbelstapel-tonnelering nie; dit is 'n grens. Om dit tonnelering te noem sal die volgende persoon wat die beleid lees verwar, en die verwarring sal opduik as 'n dienslessenaar-tiket oor 'n stukkende IPv6-werf.

Verifieer met die regte rekening, en eien dan die lewensiklus

Vergelyk opsoeke: ip -4 route get 198.51.100.25 uid 1500 teen dieselfde bestemming met 'n gewone UID. Maak dan 'n toegelate versoek onder die toegewyde rekening en kyk na die bronadres wat die verre kant sien. 'n Voorkeur-bronadres is nie bron-NAT nie, en dit sal nie 'n toepassing oorheers wat iets anders bind nie. As albei opsoeke dieselfde pad teruggee, doen die reël nie wat jy dink nie.

Hou die tabel, die reëls en die lewensduur van die tonnelroete onder een eienaar, toets 'n herverbinding en 'n tonnelverlies, en verwyder slegs sy presiese inskrywings wanneer die beleid afgetree word. 'n Naamruimte is steeds beskikbaar as afsonderlike koppelvlakke en afsonderlike toestand is wat jy werklik nodig het.