Пакет заштитног зида инсталиран, правила су нестала после поновног покретања

Пакет се инсталирао без грешке, правила су тестирана, а после следећег поновног покретања гејтвеј је био потпуно отворен. Ништа у трансакцији није отказало; отказало је оно што се претпостављало да ће остати. Инсталација алата за заштитни зид, одлука која правила треба да преживе и њихово обнављање у правом тренутку три су одвојена посла.

Шта вам симптом заправо говори

Скуп правила који нестане после поновног покретања има једног од три власника: нико га није сачувао, нешто друго га је заменило или је обновљен пре него што је постојало оно од чега зависи. Прва два се виде у конфигурацији; треће се показује само у редоследу. Зато поновно покретање може да изгледа као губитак података, иако је заправо проблем редоследа.

Почните тако што ћете записати шта је важило пре поновног покретања: која служба је држала правила, коју датотеку или базу је читала при покретању и да ли је тај извор икада био уписан. Живи скуп правила који нико није сачувао је валидно објашњење и најчешће.

Не почињите поновним инсталирањем пакета.

Прочитајте алат за трајност пре него што га употребите

Debian алати третирају трајност као проблем додатака: сваки додатак зна да упише своја правила, а један омотач их позива. Његова радња чувања памти све што је у том тренутку учитано, а радња покретања то поново учитава. Ниједна од тих радњи не прегледа шта памти.

То је снимак, а не преглед. Заборављено дозвољење из сесије за отклањање грешака, недовршен експеримент или попустљиво правило које је убацио други помоћник, све то трајно постаје део политике коју сте желели да задржите. Чување стања и одобравање стања су различите активности и само једна од њих захтева процену. Прво прочитајте учитани скуп, па онда одлучите које линије заслужују да преживе.

Чувајте свесно, након што прочитате шта је учитано.

Одлучите шта треба да преживи

Нека правила припадају животном циклусу интерфејса и треба да нестану с њим. Друга морају да надживе тунел, а најјаснији пример је ограничење које забрањује да саобраћај клијената падне назад на физички интерфејс када тунел падне. Те две категорије траже различите окидаче обнављања, а не један заједнички снимак.

Запишите жељени исход за три тренутка: покретање, активирање VPN-а и губитак тунела. Затим проверите да ли изабрани алат може да изрази сваки од њих. Пакет за трајност који поново учита статични снимак обрађује први и можда не обрађује ниједан од осталих, јер снимак не зна када се стање тунела променило. Ако не може да их изрази, празнина припада другој компоненти.

Одговор одређује политика, а не пакет.

Проверите редослед обнављања

Обновити датотеку није исто што и имати резултат. Други управљач може да замени правила, ранији accept може да их засени или клијенти могу да почну да шаљу пре него што ограничење ступи на снагу. Прегледајте понашање при покретању и поновном повезивању, не само постојање сачуване датотеке.

systemctl status netfilter-persistent
iptables -S

Не претпостављајте да је заустављање службе за трајност безазлено, јер пакет документује условно пражњење при заустављању. Пре него што на гејтвеју којим удаљено управљате употребите stop или restart као експеримент, утврдите стварну конфигурацију службе. Конзолна сесија и документовано враћање минимум су пре тог теста.

Редослед је особина система који ради, а не датотеке на диску.

Прихватите три одвојена резултата

Забележите инсталацију пакета, учитани скуп правила и спроведену политику као одвојене чињенице. Назив пакета у нити подршке одговара само на прву и управо она ретко одлучује.

nft list ruleset

Затим тестирајте дозвољену операцију и захтевано одбијање.

Ако одбијање остане након поновног покретања и након пада тунела, политика је преживела. Ако остане само у једном од тих стања, открили сте проблем редоследа, а не поправили га.