Изключение в UFW за VPN при промяна на адреса на крайната точка

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

Тунелът се свързва отново и нищо не излиза

Изходящо правило, което посочва адрес на местоназначение, е моментна снимка, а отговорите на DNS не са. Когато доставчикът завърти адрес, пакетът, който клиентът изпраща към новия партньор, не съвпада с нищо и се изхвърля от забраната по подразбиране. След това клиентът съобщава за изтекъл срок, което звучи като проблем на сървъра, а не на защитната стена.

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

Опишете изключението, което наистина имате предвид

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

Командата по-долу показва формата за една крайна точка IPv4 UDP на кабелна връзка. Заменете двете стойности с тези, които проверихте спрямо внедряването.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

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

Обновете го като един работен процес

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

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

Наблюдавайте прехода на клиента през поддържания път за повторно свързване и потвърдете кой отдалечен адрес е избрал. Обновяването само на DNS не мести съществуващ сокет, а настройка за устойчивост на крайната точка може да задържи клиента на стария партньор дълго след като записът се е променил.

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

Съзнателно изведете старото разрешение от употреба

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

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

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