방화벽 패키지는 설치됐는데 재부팅 후 규칙이 사라졌다

패키지는 깔끔하게 설치됐고 규칙도 시험했는데, 다음 재부팅 뒤 게이트웨이는 활짝 열려 있었습니다. 트랜잭션에서 실패한 것은 없으며, 실패는 무엇이 남을 것이라는 가정에 있었습니다. 방화벽 도구를 설치하는 일, 어떤 규칙이 살아남아야 할지 정하는 일, 알맞은 시점에 그것을 복원하는 일은 서로 다른 세 가지 작업입니다.

증상이 실제로 말해 주는 것

재부팅 때 사라지는 규칙 집합의 원인은 아무도 저장하지 않았거나, 다른 무언가가 대체했거나, 의존하는 대상이 생기기 전에 복원한 세 가지 중 하나입니다. 앞의 둘은 설정에서 보이지만 세 번째는 순서에서만 드러납니다. 그래서 재부팅은 데이터 손실처럼 보여도 실제로는 순서 문제입니다.

먼저 재부팅 전에 무엇이 참이었는지, 다시 말해 어느 서비스가 규칙을 들고 있었는지, 시작할 때 어느 파일이나 데이터베이스를 읽었는지, 그 원본에 쓰기가 된 적이 있는지를 적으십시오. 아무도 저장하지 않은 실행 중 규칙 집합은 타당한 설명이며 가장 흔한 경우입니다.

패키지를 다시 설치하는 것으로 시작하지 마십시오.

쓰기 전에 지속성 도구를 읽어라

Debian 도구는 지속성을 플러그인 문제로 다루며, 각 플러그인이 자기 규칙을 쓰는 방법을 알고 하나의 래퍼가 그것들을 호출합니다. 저장 동작은 그 시점에 불러온 모든 것을 기록하고, 시작 동작은 그 스냅숏을 다시 불러옵니다. 두 동작 모두 무엇을 저장하는지 검토하지 않습니다.

그것은 스냅숏이지 검토가 아닙니다. 디버깅 세션에서 남은 허용, 미완의 실험, 다른 보조 도구가 넣은 느슨한 규칙은 모두 남기려던 정책과 함께 영구히 남습니다. 상태를 저장하는 일과 상태를 승인하는 일은 다른 활동이고, 둘 중 하나만 판단을 요구합니다. 먼저 불러온 집합을 읽고, 그다음 어떤 줄이 살아남을 만한지 정하십시오.

무엇이 불러와 있는지 읽은 뒤 의도적으로 저장하십시오.

무엇이 살아남아야 하는지 정하라

어떤 규칙은 인터페이스의 수명 주기에 속하므로 함께 사라져야 합니다. 다른 규칙은 터널보다 오래 살아야 하며, 가장 분명한 예는 터널이 끊길 때 클라이언트 트래픽이 물리 인터페이스로 되돌아가는 것을 금지하는 제한입니다. 이 두 범주에는 서로 다른 복원 트리거가 필요하고, 하나의 공유 스냅숏으로는 부족합니다.

세 시점, 곧 부팅과 VPN 활성화와 터널 상실에 대해 의도한 결과를 적으십시오. 그다음 선택한 도구가 각각을 표현할 수 있는지 확인하십시오. 정적 스냅숏을 다시 불러오는 지속성 패키지는 첫 번째를 처리하지만, 스냅숏은 터널 상태가 언제 바뀌었는지 알지 못하므로 나머지는 처리하지 못할 수 있습니다. 표현할 수 없다면 그 간극은 다른 구성 요소의 몫입니다.

답을 정하는 것은 패키지가 아니라 정책입니다.

복원 순서를 확인하라

파일을 복원하는 것은 결과를 소유하는 것과 같지 않습니다. 다른 관리자가 규칙을 대체할 수 있고, 이전 허용이 그것을 가릴 수 있으며, 제한이 적용되기 전에 클라이언트가 보내기 시작할 수 있습니다. 저장된 파일의 존재만이 아니라 시작과 재연결 동작을 검토하십시오.

systemctl status netfilter-persistent
iptables -S

지속성 서비스를 멈추는 것이 무해하다고 가정하지 마십시오, 패키지는 멈출 때 조건부 플러시를 한다고 문서화합니다. 원격으로 관리하는 게이트웨이에서 멈추기나 재시작을 실험으로 쓰기 전에 서비스의 실제 구성을 확정하십시오. 콘솔 세션과 문서화된 롤백이 그 시험 전의 최소 조건입니다.

순서는 실행 중인 시스템의 성질이지 디스크 위 파일의 성질이 아닙니다.

세 가지 결과를 따로 받아들여라

패키지 설치, 불러온 규칙 집합, 적용된 정책을 각각 별개의 사실로 기록하십시오. 지원 스레드에 나오는 패키지 이름은 첫 번째에만 답하며, 바로 그것이 좀처럼 중요하지 않습니다.

nft list ruleset

그다음 허용되는 작업과 요구되는 거부를 시험하십시오.

거부가 재부팅 뒤에도, 터널이 끊긴 뒤에도 유지되면 정책은 살아남습니다. 두 상태 중 하나에서만 유지된다면, 고친 것이 아니라 순서 문제를 찾은 것입니다.