Кой притежава адреса, маршрута, DNS и защитната стена във VPN под Linux?

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

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

Устройството и неговите адреси

Тунелно устройство се създава или от мениджър, който познава профила, или от демон, който някой е стартирал ръчно. И двете схеми работят сами по себе си; смесването им не. Ако NetworkManager притежава профила, нека притежава и устройството, и не стартирайте необслужван OpenVPN-процес срещу същото име на тунел.

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

Маршрути и правила за политика

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

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

DNS винаги е отделен собственик

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

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

Състояние на защитната стена и кой го възстановява

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

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

Жизнен цикъл: зареждане, повторно свързване, разглобяване

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

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

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