Watter komponent besit werklik ’n OpenVPN-roetelimit?

’n Profiel met tweehonderd roetes werk op een masjien en installeer veertig op ’n ander. Die enjin, die integrasie wat dit begin, en die bediener wat dit voed, het elkeen iets te sê, en elkeen kan die lys op ’n ander punt stop. Om die fout as ’n enkele limiet te lees, stuur jou na die verkeerde lêer. Die meganisme bestaan uit drie fases, en die fase wat gestop het, laat sigbare bewyse wanneer jy weet waarna om te soek.

Drie fases, drie verskillende limiete

Eers ontleed die enjin die opsie en besluit of hierdie weergawe dit verstaan. Dan installeer die integrasie wat die enjin rapporteer, en sy eie kode kan die lys beperk of hervorm. Laastens besluit die bediener hoeveel roetes hy aan ’n gegewe identiteit sal stuur, voordat enige kliëntfase iets sien. Drie fases, drie plafonne, en net een daarvan is die getal in die profiel.

Om een plafon te verhoog, doen niks vir die ander nie. ’n Verwerpte gestuurde roete kan ’n beleidsbesluit op die bediener wees, ’n oorvleueling wat die kliënt opgelos het, of ’n installeerderlimiet wat die oortollige weggegooi het. Elkeen van dié het ’n ander oplossing.

Skei die drie voordat jy iets meet. ’n Ontlederfout noem ’n teken, ’n installeerderlimiet laat ’n kort roetelys, en ’n beleidsbesluit laat glad niks. Die bewyse vertel jou watter fase jy eerste moet ondersoek.

Die ontleder praat eerste

’n Onbekende opsie misluk hard en vroeg, en die foutteks noem die teken. Dit is die maklikste fase om te identifiseer: vergelyk die presiese boodskap met die geïnstalleerde enjinweergawe, want ’n opsie wat in een vrystelling bygekom het, is onbekend in die een voor dit. ’n Profiel wat uit ’n nuwer ontplooiing gekopieer is, is die gewone oorsaak van daardie verskil. Die ontleder ignoreer nooit stilweg ’n opdrag wat hy nie herken nie.

’n Aanvaarde opsie sê niks oor die resultaat nie. Die ontleding slaag, en die lys kan steeds deur die installeerder ingekort word of nooit deur die bediener aangebied word nie. Behandel ’n skoon ontleding as toestemming om voort te gaan, nie as bewys nie.

Teken die weergawestring aan uit die binêre lêer wat werklik gehardloop het, nie uit die pakketbestuurder se idee van wat geïnstalleer is nie. Dié twee stem meer dikwels nie ooreen nie as wat verwag word.

Die installeerder het sy eie plafon

Die komponent wat aktivering besit, kan ’n NetworkManager-inprop eerder as die enjinbinêre lêer wees, en dit kan sy eie limiet oplê voordat enige tonnel bestaan. Sy redigeerder kan ’n veld wys wat die lopende enjin nooit lees nie, of ’n veld lees wat die redigeerder nie wys nie. Beide situasies lyk van buite soos ’n kliëntfout. Nie een word deur die profiel te wysig reggemaak nie.

Tel wat geland het eerder as wat opgestel is. Die opdrag ip route show dev tun0 lys die geïnstalleerde roetes, en om daardie getal met die gestuurde lys te vergelyk, skei ’n weggegooide roete van een wat nooit gestuur is nie. ’n Getal wat by die stuur pas, skuif die vermoede terug na die bediener.

’n Skulomhulsel om die enjinbinêre lêer om ’n groter getal af te dwing, verduister opgraderings en maak terugrol raaiwerk. Dit verberg ook die werklike limiet vir elkeen wat die konfigurasie volgende lees.

Die bediener besluit wat aan jou aangebied is

Beleid per kliënt kan die lys verklein voordat dit versend word. ’n Kliëntspesifieke lêer kan roetes vir een identiteit byvoeg, of ’n groepsbeleid kan hulle weglaat, en die kliënt kan nie ’n roete wat gefiltreer is van een wat nooit gedefinieer is nie, onderskei nie. Daardie onduidelikheid is waarom die bedienerrekord saak maak. Vra vir die effektiewe stuurlys vir daardie identiteit, nie vir die sjabloon nie.

Vergelyk die bedienerrekord met die ontvangde lys. Die gaping tussen hulle is die beleidslaag, en dit is gewoonlik kleiner as wat die profiel voorstel.

Waar die ontwerp dit toelaat, som aangrensende netwerke op en verwyder verouderde inskrywings. Minder, groter roetes los meer gevalle op as ’n hoër plafon.

Verander die getal op die regte plek

Gebruik die gedokumenteerde instelling van die komponent wat die limiet werklik besit. As die veld in die inprop ontbreek, kyk of die inprop ouer is as die funksie of of ’n ander agterkant die roetes besit. Dokumenteer dan die enjin-, inprop- en bedienerweergawes langs die waarde wat jy gekies het. Die volgende opgradering heropen die vraag, en die nota is wat dit antwoordbaar maak.

Herhaal die toets ná enige opgradering van enige van die drie. ’n Limiet wat op die regte plek verhoog is, skuif steeds wanneer die komponent wat dit afdwing, verander. Die weergawe rekord is die enigste ding wat daardie beweging voorspelbaar maak.