Která komponenta skutečně vlastní limit tras OpenVPN?

Profil s dvěma sty trasami funguje na jednom stroji a na jiném nainstaluje čtyřicet. Jádro, integrace, která ho spouští, a server, který ho napájí, mají každý své slovo a každý může seznam zastavit v jiném bodě. Když poruchu čtete jako jediný limit, dostanete se ke špatnému souboru. Mechanismus má tři fáze a fáze, která se zastavila, zanechává viditelné stopy, když víte, co hledat.

Tři fáze, tři různé limity

Nejprve jádro analyzuje volbu a rozhodne, zda jí tato verze rozumí. Potom integrace nainstaluje to, co jádro hlásí, a její vlastní kód může seznam omezit nebo přetvořit. Nakonec server rozhodne, kolik tras odešle dané identitě, dřív než kterákoli klientská fáze něco uvidí. Tři fáze, tři stropy a jen jeden z nich je číslo v profilu.

Zvednutí jednoho stropu nedělá pro ostatní nic. Odmítnutá odeslaná trasa může být rozhodnutím politiky na serveru, překryvem, který klient vyřešil, nebo limitem instalátoru, který přebytek zahodil. Každý z těchto případů má jinou opravu.

Oddělte ty tři, než cokoli změříte. Chyba parseru pojmenuje token, limit instalátoru zanechá krátkou tabulku tras a rozhodnutí politiky nezanechá vůbec nic. Stopy vám řeknou, kterou fázi prozkoumat první.

Parser mluví první

Neznámá volba selže hlasitě a brzy a text chyby pojmenuje token. To je nejlépe rozpoznatelná fáze: porovnejte přesnou zprávu s nainstalovanou verzí jádra, protože volba přidaná v jednom vydání je v předchozím neznámá. Profil zkopírovaný z novějšího nasazení je obvyklým zdrojem tohoto nesouladu. Parser nikdy tiše neignoruje direktivu, kterou nezná.

Přijatá volba nic neříká o výsledku. Analýza projde a seznam přesto může instalátor zkrátit nebo ho server nikdy nenabídne. Berte čistou analýzu jako povolení pokračovat, ne jako důkaz.

Zapište řetězec verze z binárky, která skutečně běžela, ne z představy správce balíčků o tom, co je nainstalováno. Ty dvě se neshodují častěji, než se čeká.

Instalátor má vlastní strop

Komponenta, která vlastní aktivaci, může být zásuvný modul NetworkManageru místo binárky jádra a může prosadit svůj vlastní limit dřív, než existuje jakýkoli tunel. Její editor může ukazovat pole, které běžící jádro nikdy nečte, nebo číst pole, které editor nezobrazuje. Obě situace zvenčí vypadají jako chyba klienta. Ani jednu nevyřeší úprava profilu.

Počítejte, co dorazilo, ne co bylo nastaveno. Příkaz ip route show dev tun0 vypisuje nainstalované trasy a porovnání tohoto počtu s odeslaným seznamem odděluje zahozenou trasu od té, která nebyla nikdy odeslána. Počet, který odpovídá odeslání, vrací podezření zpět na server.

Obal skriptu kolem binárky jádra, který má vynutit větší číslo, zamlžuje aktualizace a dělá z návratu hádání. Také skrývá skutečný limit před každým, kdo bude konfiguraci číst příště.

Server rozhoduje, co vám nabídl

Politika pro jednotlivého klienta může seznam zmenšit před přenosem. Soubor specifický pro klienta může přidat trasy pro jednu identitu nebo je skupinová politika může vynechat a klient nerozezná filtrovanou trasu od trasy, která nebyla nikdy definována. Právě proto je záznam na serveru důležitý. Žádejte skutečný seznam odeslání pro danou identitu, ne šablonu.

Porovnejte záznam serveru s přijatým seznamem. Mezera mezi nimi je vrstva politiky a obvykle je menší, než profil naznačuje.

Když to návrh dovolí, shrňte sousedící sítě a smažte zastaralé položky. Méně a větších tras vyřeší víc případů než vyšší strop.

Změňte číslo na správném místě

Použijte dokumentované nastavení komponenty, která limit skutečně vlastní. Chybí-li pole v modulu, ověřte, zda je modul starší než funkce nebo zda trasy vlastní jiný backend. Potom zapište verze jádra, modulu a serveru vedle zvolené hodnoty. Příští aktualizace otázku znovu otevře a právě poznámka ji činí zodpověditelnou.

Po každé aktualizaci kterékoli ze tří znovu otestujte. Limit zvednutý na správném místě se i tak posune, když se změní komponenta, která ho prosazuje. Záznam verzí je jediná věc, která to posunutí činí předvídatelným.