VPN 인터페이스가 계속 firewalld 영역을 떠나는 이유

tun0을 올바른 영역에 추가하면 애플리케이션이 작동하기 시작하고, 다음 재연결에서 수정이 사라집니다. 같은 명령을 다시 실행하면 작동하므로 firewalld가 잊어버린 것처럼 보입니다. 잊어버린 것이 아니라 그 인터페이스에 더 강한 권한을 가진 무언가가 다시 할당한 것입니다.

영역은 인터페이스가 다시 만들어질 때까지 유지됩니다

인터페이스에 대한 firewalld 영역 할당은 바인딩이며, 바인딩은 지금 존재하는 인터페이스 객체에 묶여 있습니다. 장치를 없애고 다시 만드는 VPN 클라이언트는 새 객체를 만들고, 새 객체는 할당하는 구성 요소가 말하는 대로 시작합니다. 증상이 패킷마다가 아니라 재연결마다 반복되는 이유가 여기에 있습니다.

같은 논리가 재부팅 동작도 설명합니다 — 런타임 바인딩은 재시작을 견디지 못하고, 영구 바인딩은 firewalld가 자기 것이라고 보는 장치에만 적용됩니다.

무엇이든 바꾸기 전에 어느 구성 요소가 영역을 할당하는지 알아내세요.

무엇이든 바꾸기 전에 세 가지를 읽으세요

인터페이스가 지금 가지고 있는 영역, 인터페이스와 함께 있는 활성 영역, 그리고 의도하는 영역의 영구 인터페이스 목록을 기록하세요. 그 조회는 변경 전에, 재연결 후에, 재부팅 후에 실행하세요. 세 결과를 비교하면 바인딩이 교체되는지, 무시되는지, 아니면 단지 늦게 적용되는지 알 수 있습니다. 영구 목록이 이미 장치를 이름으로 갖고 있는데 런타임 영역이 다르다면, 무언가가 당신의 수정을 덮어쓰고 있습니다.

각 단계에서 실제 장치 이름도 기록하세요 — 오늘 tun0에 착지하는 터널이 내일은 tun1에 착지할 수 있기 때문입니다.

일반적인 이름에 저장된 바인딩은 신원 확인이 아니며, 두 분의 기록이 한 시간의 추측을 아껴 줍니다.

NetworkManager가 연결을 소유할 때

NetworkManager가 VPN 연결을 관리한다면 그 프로필이 영역을 담고 있으며, 연결이 활성화될 때 firewalld에 전달합니다. 같은 장치에 대한 firewalld의 영구 인터페이스 바인딩은 그때 무시될 수 있습니다 — 소유자가 NetworkManager이기 때문입니다. 영역은 연결에 설정하고, 관련 없는 물리적 연결이나 임시 레코드가 아니라 VPN 프로필을 편집하고 있는지 확인하세요.

그 속성을 바꾸면 활성 연결에 즉시 영향을 줄 수 있습니다.

관리 경로를 확보해 두고 적용하기 전에 대상 영역의 정책을 읽으세요. ifcfg 파일의 ZONE 필드를 편집하는 것이 올바른 경우는 그 파일이 아직 구성의 원천일 때뿐입니다.

firewalld가 바인딩을 소유할 때

의도적으로 안정적인 인터페이스 이름을 가진 독립 터널에는 영구 인터페이스 변경이 알맞은 도구입니다. 배포가 사용하는 재로드나 수명 주기를 통해 적용하고 나서 런타임 상태를 확인하세요 — 영구 설정만 고치는 일은 무엇이 활성인지가 아니라 의도를 서술하기 때문입니다. 둘은 재로드에 걸리는 시간만큼 어긋날 수 있습니다.

인터페이스 이름이 동적이라면 이름을 먼저 차지하는 터널과 경쟁하는 대신 연결 수명 주기 동안 할당을 유지하세요.

인터페이스를 trusted로 밀어 넣는 것은 애플리케이션을 작동시키기 위한 이유만으로 해서는 안 됩니다.

재로드, 재연결, 재부팅을 시험하세요

변경은 세 가지를 모두 견뎌야 끝난 것입니다.

먼저 재로드하세요 — 런타임만의 수정이 사라지는 곳이 거기입니다. 그다음 터널을 다시 연결하세요 — 교체된 인터페이스가 바인딩을 잃는 곳이 거기입니다. 그다음 재부팅하세요 — 소유자 불일치가 마침내 드러나는 곳이 거기입니다. 단계마다 영역을 기록하고 적어 둔 의도와 비교하며, 어느 단계가 차이를 만들었는지 적으세요.

영역이 올바른데도 애플리케이션이 실패한다면 문제는 멤버십이 아니라 영역의 규칙이나 출처 기반 분류에 있습니다. 연결과 인터페이스에 관한 firewalld 문서가 소유권이 어떻게 작동해야 하는지에 대한 참조입니다.

소유자, 값, 기대 결과를 runbook에 적으면 다음 재할당은 설명 가능한 일이 됩니다.