Кой компонент всъщност притежава лимита за маршрути на OpenVPN?

Профил с двеста маршрута работи на една машина и инсталира четиридесет на друга. Двигателят, интеграцията, която го стартира, и сървърът, който го храни, имат думата, и всяка от тях може да спре списъка на различно място. Ако четете повредата като един лимит, ще отидете в грешния файл. Механизмът има три етапа, а етапът, който е спрял, оставя видими следи, щом знаете какво да търсите.

Три етапа, три различни лимита

Първо двигателят разбира опцията и решава дали тази версия я познава. После интеграцията инсталира това, което двигателят съобщава, и собственият ѝ код може да ограничи или преоформи списъка. Накрая сървърът решава колко маршрута да изпрати до дадена самоличност, преди някой клиентски етап да види каквото и да е. Три етапа, три тавана, и само един от тях е числото в профила.

Вдигането на един таван не прави нищо за другите. Отхвърлен изпратен маршрут може да е политическо решение на сървъра, застъпване, което клиентът е разрешил, или лимит на инсталатора, който е изхвърлил излишъка. Всяко от тези има различно решение.

Разделете трите, преди да измервате каквото и да е. Грешка на разборника назовава токен, лимит на инсталатора оставя къса таблица с маршрути, а политическо решение не оставя нищо. Следите ви казват кой етап да проверите първо.

Разборникът говори пръв

Неизвестна опция се проваля шумно и рано, а текстът на грешката назовава токена. Това е най-лесният за разпознаване етап: сравнете точното съобщение с инсталираната версия на двигателя, защото опция, добавена в едно издание, е неизвестна в предишното. Профил, копиран от по-ново разгръщане, е обичайният източник на това несъответствие. Разборникът никога не пренебрегва мълчаливо директива, която не разпознава.

Приетата опция не казва нищо за резултата. Разборът минава, а списъкът все още може да бъде подрязан от инсталатора или никога да не бъде предложен от сървъра. Приемайте чистия разбор като разрешение да продължите, а не като доказателство.

Запишете низа на версията от двоичния файл, който действително е работил, а не от представата на пакетния мениджър какво е инсталирано. Тези две се разминават по-често от очакваното.

Инсталаторът има свой таван

Компонентът, който притежава активирането, може да е приставка на NetworkManager, а не двоичният файл на двигателя, и тя може да наложи свой лимит, преди да съществува какъвто и да е тунел. Редакторът ѝ може да показва поле, което работещият двигател никога не чете, или да чете поле, което редакторът не показва. И двете ситуации отвън изглеждат като дефект в клиента. Нито една не се поправя с редактиране на профила.

Бройте какво е пристигнало, а не какво е настроено. Командата ip route show dev tun0 изброява инсталираните маршрути и сравняването на този брой с изпратения списък отделя изхвърлен маршрут от такъв, който никога не е бил изпратен. Брой, който съвпада с изпращането, връща подозрението към сървъра.

Обвивка около двоичния файл на двигателя, която насила изтръгва по-голямо число, замъглява обновяванията и превръща връщането назад в догадка. Тя също крие истинския лимит от всеки, който чете конфигурацията след това.

Сървърът решава какво ви е предложено

Политика за всеки клиент може да свие списъка, преди да бъде предаден. Файл, специфичен за клиент, може да добави маршрути за една самоличност, или групова политика може да ги пропусне, а клиентът не може да различи филтриран маршрут от такъв, който никога не е бил дефиниран. Тази двусмисленост е причината записът на сървъра да има значение. Поискайте действителния списък за изпращане за тази самоличност, а не шаблона.

Сравнете записа на сървъра с получения списък. Разликата между тях е политическият слой и обикновено е по-малка, отколкото профилът подсказва.

Когато дизайнът го позволява, обобщете съседните мрежи и изтрийте остарелите записи. По-малко и по-големи маршрути решават повече случаи от по-висок таван.

Променете числото на правилното място

Използвайте документираната настройка на компонента, който действително притежава лимита. Ако полето липсва в приставката, проверете дали приставката е по-стара от възможността или дали друг бекенд притежава маршрутите. След това документирайте версиите на двигателя, приставката и сървъра до избраната стойност. Следващото обновяване отваря въпроса отново и бележката е това, което го прави отговорим.

Тествайте отново след всяко обновяване на някое от трите. Лимит, вдигнат на правилното място, пак се мести, когато компонентът, който го налага, се промени. Записът на версиите е единственото, което прави това движение предвидимо.