Twee OpenVPN-kliënte op een Linux-aansluitpunt: verdeel die beleid

Twee OpenVPN-daemons kan albei ’n suksesvolle tonnel rapporteer terwyl die aansluitpunt elke kliënt deur dieselfde een stuur. Niks in die handshake besluit watter tonnel ’n kliënt gebruik nie; die kernel besluit, een pakket op ’n slag, deur die beleidsreëls te loop en dan die tabel wat elke reël noem. Sodra jy dit so sien, hou die opstelling op om oor OpenVPN-opsies te gaan en word dit ’n roetematriks met twee eienaars.

Die kernel besluit, nie die daemon nie

’n Deurgestuurde pakket kom op die LAN-koppelvlak in en die roetekode evalueer die reëllys in prioriteitsorde. Die eerste reël wie se keurder pas, noem ’n tabel, en daardie tabel se roetes kies die uitvoertoestel. As die tabel geen passende roete het nie, gaan die soektog na die volgende reël voort, en dit is die besonderheid wat ’n halfvoltooide opstelling stil laat misluk eerder as hardop.

Die tonnelproses het geen sê in daardie loop nie. Dit skep ’n koppelvlak en kan roetes installeer, maar of ’n bepaalde kliënt se pakket daardie koppelvlak binnegaan, hang heeltemal van die tabel af waarna dit gestuur is. Twee tonnels met identiese ingevoerde roetes kom dus mee, en die laaste skrywer wen vir almal. Dis waarom ’n opstelling gebalanseerd in die konfigurasielêers kan lyk en steeds alle kliënte deur een daemon stuur.

Gee elke instansie sy eie hulpbronversameling

Begin met name, want hergebruikte name is hoe die twee instansies per ongeluk staat deel. Wys afsonderlike tonneltoestelle, afsonderlike konfigurasielêers, afsonderlike geloofsbriewe en afsonderlike dienseenhede toe. Teken elke instansie se buitenste eindpunt en tonneladres in dieselfde tabel as die beleidsmatriks aan, sodat ’n latere verandering een plek het om te kyk.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull hou ’n bediener se gestuurde roetes uit die plaaslike tabel, wat jy wil hê wanneer die beleidstabelle eksplisiet moet wees. Of ’n gegewe bediener ook ’n redirect-gateway-opsie stuur, en of jou kliëntweergawe die filtervorm ondersteun, is die moeite werd om in die handleiding na te gaan eerder as om aan te neem.

Skryf die matriks: bron, tabel, toestel

Voeg vir elke kliëntgroep ’n reël by wat ’n tabel op bronadres kies, en plaas dan die beoogde pad in daardie tabel:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Die tabel benodig die bestemmingsroetes wat die groep behoort te hê, plus watter plaaslike of bestuurs-uitsonderings ook al die aansluitpunt bruikbaar hou. ’n Tabel met slegs ’n verstek is ’n voltonnel-beleid vir daardie groep, wat miskien heeltemal reg is, maar dit behoort ’n besluit te wees eerder as ’n weglating.

Die tonnel se eie vervoer is nie in ’n kliëntgroep nie

Elke daemon se geënkripteerde pakkette ontstaan op die aansluitpunt self, gerig aan die buitenste portuur. ’n Reël wat slegs ’n kliëntbronvoorvoegsel pas, laat daardie pakkette alleen, en daarom is bronbeperkte reëls veiliger as reëls wat alles pas. ’n Reël met geen keurder kan die tonnel se eie vervoer vasvang en dit deur ’n tonnel terugstuur, en die verbinding misluk dan op ’n manier wat soos ’n verskafferprobleem lyk.

Hou die plaaslike bestuursessie en die onderlaagpad duidelik buite die beleidstabelle. Skryf daardie uitsonderings langs die matriks neer; hulle is deel van die ontwerp, nie ’n omweg wat tydens ’n voorval herontdek moet word nie.

Om ’n pad te kies permitteer dit nie

Deurstuurtoestemming is ’n tweede besluit wat later in die pad geneem word. ’n Brandmuurreël wat pakkette aanvaar wat deur die tweede tonnel vertrek, maak nie dat die roetekode dit kies nie, en ’n korrekte tabel verleen nie toestemming om deur te stuur nie. Albei moet bestaan, en ’n toets wat slegs een van hulle bewys, sal jou oor die ander mislei. Wanneer een groep werk en die ander nie, ondersoek hierdie twee stappe afsonderlik eerder as om die tabelle te herskryf.

Brontranslasie is ’n derde besluit, en dit moet beperk word tot die brongrupp en die tonneltoestel wat dit werklik dra. Voeg ’n toegewyde ketting vir die twee instansies by eerder as om die postrouting-ketting te spoel, want onverwante dienste kan inskrywings daar besit en ’n spoeling verwyder hulle stilweg.

Wat gebeur wanneer een tonnel wegval

Bespreek die foutgedrag vooraf. Wanneer ’n tonneltabel sy roete verloor, val die soektog deur na die volgende reël, en die groep se verkeer gaan sonder enige fout deur die ander tonnel of die gewone opstuurpad voort. As dit nie aanvaarbaar is nie, voeg ’n beëindigingsreël by ’n laer prioriteitsnommer by wat ’n onbereikbare resultaat vir daardie bron teruggee, sodat die verlies sigbaar is eerder as om geabsorbeer te word.

Stuur ’n vars versoek van elke brongrupp en teken vier feite op: die tabel wat gekies is, die uitvoertoestel, die vertaalde bron, en of die antwoord deur dieselfde pad teruggekom het. Bring dan een tonnel af en herhaal. Twee TUN-toestelle in ’n koppelvlaklys bewys dat albei daemons begin het; hulle sê niks oor watter een ’n gegewe kliënt gebruik het nie. Die tweede lopie, met een tonnel weg, is die een wat wys of jou terugvalreël doen wat jy bedoel het.