Hou private roetes en laat die herleiding weg: OpenVPN se gesplete tonnel
'n Tonnel net vir private netwerke het twee reëls nodig: private voorvoegsels gaan daardeur, gewone blaaiery behou sy plaaslike pad. Die verwydering van 'n verstekroete is nie 'n beleid nie.
Die tonnel kom op, die toepassing laai, en dan begin alles anders op die skootrekenaar vreemd optree. Dit is die gewone vorm van 'n beleid net vir private netwerke wat deur die verwydering van een reël geïmplementeer word. Die verwydering van 'n gestuurde verstekroete verander wel waar die verkeer gaan, maar dit sê nie waar die verkeer eerder moet gaan nie, en dit raak glad nie naamresolusie nie. 'n Beleid het twee positiewe helftes nodig voordat dit getoets kan word.
Die verwydering van die herleiding is net die helfte van die verandering
'n Herleiding van die volle tonnel en 'n beleid net vir private netwerke verskil in wat hulle oor die wêreld beweer. Die herleiding eis elke bestemming, terwyl die private beleid 'n lys eis en die res met rus laat. Om die eis te verwyder sonder om die lys te skryf, lewer 'n kliënt wat niks buite die LAN bereik nie, wat soos 'n roetefout lyk eerder as 'n leemte in die beleid. Skryf die lys voordat jy die eis verwyder, en die volgorde van daardie twee stappe hou op om saak te maak.
Albei helftes is vereistes eerder as verstekke. Private voorvoegsels moet die tonnel binnegaan, en gewone bestemmings moet die pad behou wat hulle voor die verbinding gehad het.
As 'n organisasie die volle tonnel verplig, geld niks hiervan nie. Die ontwerp net vir private netwerke hoort by ontplooiings waar gesplete roetering goedgekeur is.
pull-filter is 'n passing, nie 'n skakelaar nie
Die pull-filter-rigting verwyder gestuurde opsies waarvan die name by 'n voorvoegsel pas, en dit is al wat dit doen. Om die herleiding te ignoreer, laat elke ander gestuurde opsie in plek, wat gewoonlik is wat jy wil hê: roetes, DNS-instellings en die roete-gateway-waarde kom steeds aan. Dit kan ook nie 'n rigting verwyder wat in die plaaslike profiel geskryf is nie, want filterwerk geld vir wat die bediener stuur.
Weerstaan die versoeking om elke opsie wat met route begin, te ignoreer. Daardie patroon verwerp ook die private roetes wat die verbinding nodig het, en dit kan gateway-inligting laat val waarvan die tonnel afhanklik is.
route-nopull is 'n wyer besluit as wat dit lyk. Dit keer dat die kliënt gestuurde roetes en DHCP-agtige opsies as 'n groep aanvaar, wat 'n ander beleid is as om een opsie uit te filter.
Skryf die roetelys van die toepassing af uitwaarts
Begin by wat die gebruiker werklik oopmaak, en voeg dan die ondersteunende dele by. 'n Toepassing by 10.60.20.15 impliseer sy subnet 10.60.0.0/16, en 'n private naam impliseer die oplosser wat dit beantwoord. 'n Gebruiker wat een toepassing gevra het, het dus twee bestemmings en een DNS-besluit nodig. Alles buite daardie lys is per konstruksie buite bestek, en dit is wat die beleid hersienbaar hou.
Op 'n samewerkende bediener word dit twee gestuurde roetes, en nie een daarvan is 'n herleiding nie. Behou die tonnel-topologie en roete-gateway-waardes wat die bestaande diens verskaf.
Wanneer net sommige gebruikers hierdie beleid nodig het, pas dit per kliënt of per groep toe. Om almal se roetering te verander om een span se vereiste reg te maak, is hoe 'n gesplete tonnel 'n onderbreking word.
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
Laat DNS dieselfde pad volg
'n Roete na die oplosser is nie 'n oplosserbeleid nie. Op 'n systemd-resolved-kliënt is die semantiese resultaat 'n roeteringsdomein vir die private naamruimte wat na die interne oplosser wys, en dit is wat maak dat net daardie name dit gebruik. 'n Windows-kliënt het eerder sy eie naamruimtebeleid-meganisme nodig. 'n DNS-bedienerlyn in die profiel installeer nie een van dié dinge op sy eie nie.
Kontroleer wat die bedryfstelsel gekies het eerder as wat die profiel aangevra het. Op Linux wys resolvectl status die domein en bediener per skakel; op Windows is die naamruimtebeleid-tabel die ekwivalente bewys.
Hou die oplosser bereikbaar deur die tonnel, anders wys die beleid na 'n adres wat nie bevraag kan word nie. 'n Oplosseradres wat die tonnel nie kan bereik nie, verander 'n werkende beleid in 'n tydsverloop.
Verifieer albei helftes by 'n herverbinding
Herverbind die kliënt ná die verandering en ondersoek die effektiewe roete na 'n private adres en na 'n openbare een. Los dan 'n private naam en 'n openbare naam op en bevestig dat elkeen die bedoelde oplosser gebruik het. 'n Openbare webwerf wat laai, bewys net die tweede helfte, en dit is die helfte wat gewoonlik per ongeluk werk.
Teken die voltooide beleid in een sin op: hierdie voorvoegsels en name gebruik hierdie verbinding, alles anders volg die plaaslike pad. Hou dit dan in die profiel eerder as om adapter-instellings ná elke aanmelding te herstel.