Защо изтрит VPN маршрут се връща след повторно свързване

Изтриването на активен маршрут не променя нищо, когато профил, push или boot unit го създава наново. Намерете собственика, променете го там и проверете при повторно свързване.

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

Кой е инсталирал маршрута

Започнете със списък с кандидати, а не с поправка. VPN профилът може да носи собствени маршрути, сървърът може да ги изпраща при свързване, профилът на мрежовия мениджър може да ги декларира, boot unit или скрипт може да ги добавя, а реализациите на IPsec инсталират маршрути за селекторите на трафик, които договарят. Правилата за маршрутизация по политика също могат да пренасочат трафика изцяло към друга таблица.

Времето ги разделя по-бързо от конфигурационната археология. Запис, който се появява в момента, в който интерфейсът се вдигне, принадлежи на клиента; такъв, който пристига секунда по-късно, обикновено идва от push от сървъра; такъв, който е налице при зареждане, принадлежи на запазената конфигурация. Запишете таблицата преди и след свързване, прекъсване и рестарт и моделът ще посочи собственика. Маршрут, който се връща само при рестарт на услугата, сочи към unit, а не към VPN.

Прочетете таблицата, преди да я редактирате

Гледайте собствената гледна точка на ядрото, а не запазен файл. Колоната за протокол показва какво е инсталирало всеки запис:

ip route show
ip route show table all
ip rule show

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

След това попитайте ядрото кой маршрут би използвал всъщност. Защитен адрес е по-добра проба от публичен:

ip route get 10.20.5.7

Променете собственика, а не симптома

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

Запазете изключването на крайната точка. Маршрут до хост, който изпраща собствения публичен адрес на VPN сървъра през физическия шлюз, е това, което поддържа потока на външните тунелни пакети; изтрийте го и тунелът ще се опита да носи себе си. При split-tunnel профил същата грижа важи за локалните подмрежи, които трябва да заобикалят тунела.

Свържете се отново и проверете двата пътя

Свържете се отново, след което проверете двете дестинации наведнъж. Защитеният адрес и изключената крайна точка отговарят на различни въпроси:

ip route get 10.20.5.7
ip route get 198.51.100.20

Първият трябва да се разреши през тунелния интерфейс, а вторият през физическия шлюз. Ако и двата се разрешат през тунела, изключването липсва; ако нито един, промяната в профила не е влязла в сила и гледате друг собственик, различен от този, който сте мислили.

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

Подобни статии