firewalld의 현재 적용 설정인 runtime을 바꿔도 permanent에 자동 저장되지는 않습니다. 같은 zone에서 runtime에만 추가한 서비스는 reload로 permanent를 다시 읽으면 해당 서비스 허용 목록에서 사라질 수 있습니다.
확인 순서는 사용 중인 zone 찾기, 같은 zone의 두 설정 조회, 어느 방향으로 상태가 바뀌는지 설명하기입니다. 서비스 목록에 없다는 사실만으로 모든 경로의 포트가 차단됐다고 결론 내리지는 마세요.
1. 현재 적용 상태와 저장 상태를 나눕니다
공식 문서는 runtime을 현재 커널 방화벽에 적용되는 설정으로, permanent를 설정 파일에 저장된 상태로 구분합니다. 서비스 시작이나 reload 때는 permanent가 새 runtime의 바탕이 됩니다. 따라서 ‘명령이 성공했다’와 ‘다음 reload 후에도 같은 상태다’는 서로 다른 확인입니다. 이 구분은 firewalld를 사용하는 환경에 해당합니다.
| 시점 | public zone의 runtime | public zone의 permanent |
|---|---|---|
| 기존 서비스의 runtime 추가 전 | https 없음 | https 없음 |
| runtime에만 https를 추가한 뒤 | https 있음 | https 없음 |
| 성공적으로 reload한 뒤 | https 없음 | https 없음 |
표의 마지막 줄은 방화벽 전체가 닫혔다는 뜻이 아닙니다. 같은 포트를 다른 서비스, 개별 포트 규칙, 다른 허용 경로가 열고 있을 수도 있습니다. 여기서 확인한 것은 public zone의 https 서비스 등록 상태뿐입니다. 답안도 확인한 대상과 범위를 그대로 적어야, 서비스 목록 조회를 네트워크 연결 시험으로 잘못 읽지 않게 됩니다.
2. 같은 zone에 대해 두 번 조회합니다
firewall-cmd --state
firewall-cmd --get-active-zones
# public은 예시입니다. 실제 트래픽에 적용되는 zone을 먼저 확인합니다.
firewall-cmd --zone=public --query-service=https
firewall-cmd --permanent --zone=public --query-service=https조회 명령의 --permanent 유무를 제외한 zone과 service 이름은 같아야 합니다. runtime의 public과 permanent의 다른 zone을 비교하면 저장 여부가 아니라 서로 다른 대상을 비교하게 됩니다. --get-active-zones는 인터페이스나 source가 연결된 활성 zone을 보여 줍니다. 기본 zone 이름만 외워 실제 트래픽의 적용 대상을 대신하지 마세요.
정상적인 단일 --query-service 조회에서는 등록되어 있으면 종료 코드 0, 없으면 1입니다. 1이라는 숫자를 무조건 도구 고장으로 해석하지 마세요. 반대로 권한 오류나 서비스 미실행 같은 다른 오류를 ‘없음’과 합치면 안 됩니다. 실행한 명령, 조회 대상, 출력, 종료 코드를 같이 기록하면 부정 응답과 명령 실패를 나눌 수 있습니다.
3. reload와 저장은 방향이 반대입니다
| 동작 | 이동 방향 | 읽을 때 주의할 점 |
|---|---|---|
| reload | permanent → runtime | 현재 임시 서비스 변경을 저장하는 명령이 아닙니다. |
| runtime-to-permanent | runtime → permanent | 의도하지 않은 현재 변경까지 저장할 수 있습니다. |
| permanent 옵션으로 서비스 변경 | permanent만 변경 | 해당 서비스의 현재 적용 상태는 별도로 확인합니다. |
‘저장하려고 reload했다’는 설명은 방향이 뒤집혀 있습니다. 반대로 현재 설정을 영구 설정으로 옮기면 실험 중 넣은 불필요한 허용 규칙까지 남을 수 있습니다. 실습에서는 두 상태의 차이를 먼저 적고, 남겨야 할 항목과 버려야 할 항목을 결정한 뒤 변경 계획을 세우세요. 이 글의 조회 예시는 운영 장비의 reload나 일괄 저장을 지시하는 절차가 아닙니다.
또 기존 https 서비스를 zone에서 허용하는 일과 새 서비스 정의를 만드는 일은 다릅니다. 서비스 정의를 추가했다고 모든 zone이 그 서비스를 자동 허용하는 것으로 읽으면 안 됩니다. ‘서비스가 존재한다’, ‘이 zone에서 허용한다’, ‘실제 접속이 된다’를 각각 다른 문장으로 설명해 보세요. 서로 다른 질문에 필요한 확인도 달라집니다.
4. 불일치 사례를 읽는 순서
- 도구가 firewalld인지와 조회가 정상 수행됐는지 확인합니다. 명령 실패와 서비스 미등록을 구분합니다.
- 실제 대상 zone을 정하고 runtime·permanent를 같은 서비스 이름으로 조회합니다.
- 두 결과를 표에 적고, 다음 동작이 저장인지 다시 읽기인지 화살표로 표시합니다.
- 설정 변경이 허용된 실습이라면 적용 후 두 설정을 재조회하고 별도의 연결 시험을 계획합니다. 재조회만으로 통신 성공을 주장하지 않습니다.
반대 사례도 풀어 보세요. runtime에는 https가 없고 permanent에는 있다고 가정하면, 성공적인 reload 뒤 해당 zone의 runtime 서비스 목록에는 https가 나타납니다. 두 곳 모두 있으면 이 서비스 항목에 관한 불일치는 없습니다. 하지만 그 상태만으로 웹 서버가 실행 중인지, 요청이 올바른 인터페이스로 들어오는지는 알 수 없습니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
같은 zone의 https 조회가 runtime에서는 등록됨(0), permanent에서는 미등록(1)입니다. 설정 오류 없이 reload했다면 이 서비스 항목은 어떻게 되며, 무엇까지는 아직 알 수 없나요?
정답과 해설 확인
새 runtime에는 해당 https 서비스 항목이 없습니다. 다만 다른 허용 규칙과 실제 서버·경로 상태를 확인하지 않았으므로 전체 포트 차단이나 접속 실패까지 확정할 수는 없습니다.reload는 permanent를 다시 적용하는 방향입니다. 단일 서비스 조회 결과와 전체 방화벽 동작·종단 간 연결 시험을 분리해야 합니다.