VPN маршрут по подразбиране в таблица 200 скрива вашия LAN маршрут

Четири проверки отделят дефект в таблицата на политиките от дефект в маршрутизацията: кое правило е съвпаднало, коя таблица е посочило това правило, какво съдържа тази таблица и кой маршрут в нея е спечелил. Основната таблица не се пита, щом по-ранна таблица върне маршрут, затова запис за LAN, видим там, може да е без значение за пакета, който тествате. Изпълнете проверките по ред и липсващият маршрут ще се появи на третата стъпка, а не на четвъртата.

Съпоставянето по най-дълъг префикс се извършва в една таблица; то не сравнява маршрутите на всички таблици като един списък.

Търсенето свършва при първата таблица, която отговори

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

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

Поставете изключението за LAN там, където му е мястото

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

Какъвто и да е моделът, изключението трябва да е видимо там, където е дефинирана политиката. Маршрут, добавен на ръка и незаписан, ще изчезне при следващото рестартиране и ще отнесе диагностиката със себе си.

Не копирайте основната таблица изцяло

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

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

Проверявайте отговорите отделно от маршрутите

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

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

Запишете правилото, таблицата, спечелилия маршрут и пътя на отговора. Този запис отделя грешка в политиката от счупена услуга.