로그인 회원가입
모두인포
전체IT경제사회생활스포츠시사여행연애
IT

Linux 방화벽과 iptables/nftables 완벽 이해

admin · 2026-10-22 · 조회 4
Linux 방화벽과 iptables/nftables 완벽 이해

Linux 방화벽과 iptables/nftables 완벽 이해


1. 들어가며: 서버에서 포트가 열려 있는데 왜 접속이 안 될까?

Linux 서버에서 웹 서비스를 운영한다고 가정해 보겠습니다.


  • 서버 IP: 192.168.10.50
  • 서비스: Nginx
  • 포트: TCP 8080
  • 클라이언트 IP: 192.168.10.100

서버에서 다음 명령어를 실행했습니다.


ss -lntp | grep ':8080'

결과는 다음과 같습니다.


LISTEN 0 511 0.0.0.0:8080 0.0.0.0:*

서비스는 정상적으로 TCP 8080번 포트에서 대기하고 있습니다. 그런데 다른 PC에서 접속하면 연결이 실패합니다.


curl -v --connect-timeout 3 http://192.168.10.50:8080/

이때 의심해야 할 대상 중 하나가 바로 Linux 방화벽입니다.

서버의 서비스가 실행 중이라는 사실과 외부에서 해당 서비스에 접근할 수 있다는 사실은 서로 다릅니다. 방화벽이 패킷을 차단하면 애플리케이션까지 요청이 도달하지 않을 수 있습니다.

서버 통신 장애를 분석할 때는 다음 항목을 구분해야 합니다.


  1. 네트워크 인터페이스와 IP 설정
  2. 라우팅 경로
  3. 서비스의 LISTEN 상태
  4. Linux 방화벽 규칙
  5. 네트워크 중간 장비의 ACL 또는 방화벽
  6. 애플리케이션의 응답 상태

이번 편에서는 이 중 Linux 운영체제 내부에서 동작하는 방화벽을 집중적으로 살펴보겠습니다.



2. Linux 방화벽이란 무엇인가?

Linux 방화벽은 네트워크 패킷을 검사하고 정책에 따라 허용하거나 차단하는 기능입니다.

예를 들어 서버에 SSH, HTTP, HTTPS 서비스가 있다고 가정하겠습니다.


                    Client
                       |
                       v
                Network Interface
                       |
                       v
                Linux Network Stack
                       |
                       v
                  Firewall
                 /    |    \
                /     |     \
           TCP 22  TCP 80  TCP 443
             허용     허용     허용
                       |
                       v
                 Application

이 그림은 개념적인 흐름입니다. 실제 패킷이 통과하는 경로는 패킷의 목적지, 로컬 생성 여부, NAT 사용 여부, 커널의 네트워크 처리 과정에 따라 달라집니다.

방화벽은 IP 주소, 프로토콜, 포트, 연결 상태, 인터페이스 등 다양한 조건을 기준으로 규칙을 적용할 수 있습니다.

예를 들어 다음과 같은 정책을 구성할 수 있습니다.

정책동작TCP 22 허용SSH 원격 접속 허용TCP 443 허용HTTPS 접속 허용TCP 3306 차단외부에서 MySQL 접속 차단특정 IP만 TCP 5432 허용지정된 서버에서만 PostgreSQL 접근 허용비정상적인 연결 패킷 차단정의된 보안 정책에 따라 패킷 제한

방화벽은 단순히 포트를 열고 닫는 도구가 아닙니다. 서버를 보호하고 네트워크 접근을 통제하는 보안 정책의 일부입니다.


3. Linux 방화벽 구성 요소 이해하기

Linux에서 방화벽을 운영할 때 자주 접하는 이름은 다음과 같습니다.


  • Netfilter
  • nftables
  • iptables
  • firewalld

각 구성 요소의 역할은 다릅니다.


3.1 Netfilter

Netfilter는 Linux 커널의 네트워크 패킷 처리 기능을 제공하는 프레임워크입니다.

패킷 필터링, NAT, 연결 추적 등의 기능이 Netfilter와 연관되어 있습니다.


3.2 nftables

nftables는 Linux에서 방화벽 규칙을 정의하고 관리하는 현대적인 패킷 필터링 도구입니다.

규칙은 일반적으로 nft 명령어로 확인하고 관리합니다.


3.3 iptables

iptables는 오랫동안 Linux 방화벽 규칙을 관리하는 데 사용된 도구입니다.

기존 서버와 운영 스크립트에서 여전히 자주 발견되므로 시스템 엔지니어는 규칙 구조와 기본 명령어를 이해해야 합니다.

최근 Linux 환경에서는 iptables 명령어가 nftables 기반 호환 계층을 통해 동작하는 경우도 있습니다. 따라서 iptables 명령어가 존재한다고 해서 반드시 레거시 커널 규칙 체계를 사용한다고 단정해서는 안 됩니다.


3.4 firewalld

firewalld는 방화벽 정책을 영역(Zone), 서비스, 포트 등의 단위로 관리할 수 있도록 제공하는 방화벽 관리 서비스입니다.

Rocky Linux와 RHEL 계열에서 흔히 사용됩니다.


관리자
  |
  +-- firewall-cmd
  |       |
  |       v
  |    firewalld
  |       |
  |       v
  |    nftables 또는 환경에 맞는 백엔드
  |
  +-- nft 명령어 ------> nftables 규칙
  |
  +-- iptables 명령어 -> iptables 인터페이스

이 구조는 개념도입니다. 실제 백엔드와 호환 계층은 배포판 버전과 설정에 따라 달라집니다.

중요: firewalld가 관리하는 규칙과 nft 또는 iptables로 직접 추가한 규칙을 무계획하게 혼용하면 정책을 추적하기 어려워질 수 있습니다. 먼저 현재 서버가 어떤 관리 방식을 사용하는지 확인해야 합니다.



4. firewalld 상태와 기본 설정 확인

Rocky Linux 또는 RHEL 계열 서버에서 먼저 방화벽 서비스 상태를 확인합니다.


systemctl status firewalld

활성화 여부를 간단하게 확인하려면 다음 명령어를 사용할 수 있습니다.


firewall-cmd --state

정상적으로 실행 중이라면 다음과 같은 결과가 나올 수 있습니다.


running

현재 활성화된 영역을 확인합니다.


firewall-cmd --get-active-zones

기본 영역은 다음 명령어로 확인합니다.


firewall-cmd --get-default-zone

현재 영역의 규칙을 확인합니다.


firewall-cmd --list-all

예시:


public
  target: default
  interfaces: ens160
  services: cockpit dhcpv6-client ssh
  ports: 8080/tcp
  protocols:
  forward: yes
  masquerade: no

이 결과는 예시이며 실제 서버 설정에 따라 다릅니다.

출력 항목은 다음과 같이 해석합니다.

항목의미public적용 중인 영역interfaces해당 영역에 연결된 인터페이스services허용하도록 등록된 서비스ports허용하도록 등록된 포트masquerade해당 영역의 IP 위장(NAT) 설정 여부forward영역의 전달 관련 설정

firewall-cmd --list-all에 특정 포트가 보이지 않는다고 해서 무조건 그 포트가 차단된 것은 아닙니다. 다른 영역, 다른 규칙, 직접 설정한 nftables 규칙, 외부 방화벽 등이 영향을 줄 수 있습니다.

따라서 방화벽 정책을 전체적으로 이해하려면 여러 계층을 함께 확인해야 합니다.



5. firewalld에서 포트 허용하기

TCP 8080번 포트를 허용하는 예시를 살펴보겠습니다.


5.1 현재 영역 확인

먼저 인터페이스와 영역을 확인합니다.


firewall-cmd --get-active-zones

예를 들어 서비스가 public 영역에 연결된 인터페이스를 통해 들어온다면 해당 영역을 확인합니다.


firewall-cmd --zone=public --list-all

5.2 임시 규칙 추가

다음 명령어는 실행 중인 방화벽에 TCP 8080번 포트를 추가합니다.


firewall-cmd --zone=public --add-port=8080/tcp

일반적으로 이 변경은 런타임 설정에 적용되며 영구 설정으로 저장되지 않습니다.


5.3 영구 규칙 추가

재부팅 이후에도 유지해야 한다면 다음 명령어를 사용합니다.


firewall-cmd --zone=public --permanent --add-port=8080/tcp

영구 설정을 추가한 후에는 런타임 설정에 반영하기 위해 reload가 필요할 수 있습니다.


firewall-cmd --reload

5.4 규칙 적용 확인

런타임 설정을 확인합니다.


firewall-cmd --zone=public --list-ports

영구 설정을 별도로 확인하려면 다음과 같이 실행합니다.


firewall-cmd --permanent --zone=public --list-ports

운영 주의사항: 영구 규칙을 추가한 직후 reload를 수행하면 현재 런타임에서만 존재하던 다른 규칙이 사라질 수 있습니다. 영구 설정과 런타임 설정이 서로 다른 서버에서는 먼저 차이를 확인한 뒤 reload 여부를 결정해야 합니다.

SSH 원격 접속 중이라면 SSH 허용 정책과 현재 접속 경로를 확인하지 않은 채 방화벽을 재시작하거나 규칙을 변경하지 마십시오.



6. 포트 번호 대신 서비스 이름으로 허용하기

firewalld는 미리 정의된 서비스 이름을 이용해서 포트를 허용할 수 있습니다.

예를 들어 HTTPS 서비스를 허용하려면 다음과 같이 실행합니다.


firewall-cmd --zone=public --add-service=https

영구 설정은 다음과 같습니다.


firewall-cmd --zone=public --permanent --add-service=https

SSH 서비스도 같은 방식으로 등록할 수 있습니다.


firewall-cmd --zone=public --permanent --add-service=ssh

등록된 서비스 이름은 다음 명령어로 확인할 수 있습니다.


firewall-cmd --get-services

포트와 서비스 이름은 관리 편의성에서 차이가 있습니다.

방법예시특징포트 기반8080/tcp사용자 정의 포트에 적합서비스 기반https잘 알려진 서비스의 정책 관리에 편리

서비스 이름이 실제로 어떤 포트와 프로토콜에 연결되는지는 해당 서비스 정의를 확인해야 합니다.

운영 환경에서는 실제 애플리케이션이 사용하는 포트와 방화벽에 등록한 서비스가 일치하는지 검증해야 합니다.



7. 특정 IP 주소만 포트에 접근하도록 제한하기

외부 전체에 포트를 개방하는 대신 특정 IP 주소만 허용해야 하는 경우가 있습니다.

예를 들어 관리 서버 192.168.10.100에서만 TCP 5432번 PostgreSQL 포트에 접근하도록 제한한다고 가정하겠습니다.

이때 단순히 public 영역에 5432번을 열어 두는 방식은 요구사항에 적합하지 않을 수 있습니다.

firewalld의 rich rule을 이용하면 출발지 IP 주소를 조건으로 지정할 수 있습니다.


firewall-cmd --zone=public \
  --add-rich-rule='rule family="ipv4" source address="192.168.10.100/32" port port="5432" protocol="tcp" accept'

영구 규칙은 다음과 같습니다.


firewall-cmd --zone=public --permanent \
  --add-rich-rule='rule family="ipv4" source address="192.168.10.100/32" port port="5432" protocol="tcp" accept'

다만 이 허용 규칙만 추가한다고 해서 다른 출발지의 접속이 자동으로 차단된다고 단정할 수는 없습니다. 기존에 전체 포트 허용 규칙이 있다면 그 규칙이 여전히 적용될 수 있기 때문입니다.

특정 출발지 IP만 허용하려면 다음을 함께 확인해야 합니다.


  1. 기존의 5432/tcp 전체 허용 규칙이 있는지 확인합니다.
  2. 기존 허용 서비스나 rich rule을 검토합니다.
  3. 필요한 출발지에 대한 허용 정책을 구성합니다.
  4. 나머지 출발지의 접근이 실제로 차단되는지 검증합니다.
  5. 다른 방화벽 계층과 중복 정책이 없는지 확인합니다.

데이터베이스는 가능하면 애플리케이션 서버나 관리 네트워크에서만 접근할 수 있도록 제한하고, 데이터베이스 자체의 인증과 권한 설정도 별도로 적용해야 합니다.



8. nftables 기본 구조와 규칙 확인

nftables는 테이블, 체인, 규칙을 조합하여 패킷 필터링 정책을 구성합니다.

일반적인 구조는 다음과 같습니다.


nftables
   |
   v
Table
   |
   v
Chain
   |
   v
Rule
   |
   v
Verdict
  • Table: 규칙을 그룹화하는 단위
  • Chain: 특정 처리 지점에서 규칙을 평가하는 목록
  • Rule: 패킷을 어떤 조건으로 처리할지 정의
  • Verdict: 패킷을 허용하거나 차단하는 등의 처리 결과

8.1 현재 규칙 전체 확인

nft list ruleset

특정 테이블만 확인하려면 테이블 이름을 알아야 합니다.


nft list table inet filter

단, inet filter 테이블이 실제로 존재할 때만 사용할 수 있습니다.

현재 서버의 테이블을 먼저 확인하려면 다음 명령어를 사용합니다.


nft list tables

체인 구조를 포함해 상세히 살펴보려면 다음 명령어를 사용할 수 있습니다.


nft -a list ruleset

-a는 규칙의 핸들 번호 등 추가 정보를 보여 줍니다. 이 번호는 특정 규칙을 관리할 때 유용합니다.


8.2 nftables에서 반드시 알아야 할 점

nftables 규칙이 존재한다고 해서 해당 규칙이 반드시 모든 트래픽에 적용되는 것은 아닙니다.

다음 조건을 확인해야 합니다.


  • 패킷이 해당 체인에 도달하는가?
  • 체인이 적절한 hook과 우선순위에 연결되어 있는가?
  • 규칙이 어떤 인터페이스와 주소를 대상으로 하는가?
  • 규칙의 순서와 verdict가 적절한가?
  • 다른 체인이나 다른 방화벽 계층의 규칙이 영향을 주는가?

따라서 방화벽 규칙을 분석할 때는 단순히 규칙 문자열만 읽지 말고, 해당 규칙이 실제 패킷 처리 경로에 있는지 확인해야 합니다.



9. nftables 규칙 추가 예시

다음은 nftables에서 규칙을 구성하는 개념적인 예시입니다.

운영 중인 서버에 적용하기 전에 현재 규칙을 반드시 확인해야 합니다. 기존 테이블이나 체인이 이미 있다면 아래 예시를 그대로 실행해서는 안 됩니다.


9.1 테스트용 테이블과 체인 구성

아래 예시는 별도의 테스트 환경에서 사용할 수 있는 독립적인 IPv4 필터링 테이블입니다.


nft add table ip se_demo

입력 트래픽을 처리할 체인을 생성합니다.


nft 'add chain ip se_demo input { type filter hook input priority 0; policy accept; }'

이 체인은 기본 정책을 accept로 설정합니다. 따라서 이 예시만으로 서버 전체의 기본 차단 정책이 만들어지는 것은 아닙니다.


9.2 특정 TCP 포트 허용 규칙 추가

nft add rule ip se_demo input tcp dport 8080 accept

이 규칙은 해당 체인에 도달한 TCP 목적지 포트 8080번 패킷을 허용합니다.

하지만 체인의 기본 정책이 accept이므로 이 규칙만으로 다른 포트를 차단하지는 않습니다.


9.3 출발지 IP 주소 조건 추가

특정 출발지 IP 주소에서 오는 TCP 8080번 패킷만 일치시키는 예시는 다음과 같습니다.


nft add rule ip se_demo input \
  ip saddr 192.168.10.100 \
  tcp dport 8080 accept

여기서도 규칙의 의미를 정확히 이해해야 합니다. 이 규칙은 조건에 맞는 패킷을 허용하지만, 일치하지 않는 패킷을 자동으로 차단하지는 않습니다.

또한 se_demo라는 별도 체인을 만들었다고 해서 모든 입력 패킷이 그 체인으로 자동 전달되는 것은 아닙니다. 체인은 지정한 hook을 통해 연결되어야 합니다. 위 예시에서는 input hook에 연결했으므로 해당 경로에서 규칙이 평가됩니다.

실무에서는 firewalld가 관리하는 서버에 별도의 nftables 규칙을 임의로 추가하지 않는 것이 좋습니다. 관리 도구 간 정책 충돌을 피하려면 먼저 현재 운영 체계와 방화벽 관리 방식을 파악해야 합니다.



10. iptables 기본 명령어 이해하기

기존 Linux 서버와 운영 스크립트에서는 여전히 iptables를 자주 만날 수 있습니다.


10.1 현재 규칙 확인

iptables -L -n -v

라인 번호를 함께 확인하려면 다음과 같이 실행합니다.


iptables -L INPUT -n -v --line-numbers

NAT 규칙은 별도로 확인합니다.


iptables -t nat -L -n -v

주요 체인은 다음과 같습니다.

체인주요 역할INPUT로컬 서버를 목적지로 하는 패킷OUTPUT로컬 서버에서 생성된 패킷FORWARD서버를 통과하여 다른 목적지로 전달되는 패킷PREROUTING라우팅 결정 전 패킷 처리POSTROUTING라우팅 결정 후 패킷 송신 처리

이 구분은 기본 개념입니다. 실제 처리 경로는 NAT, 라우팅, 연결 추적과 규칙 구성에 따라 달라집니다.


10.2 TCP 8080번 허용 규칙 예시

다음 명령어는 INPUT 체인에 TCP 목적지 포트 8080번을 허용하는 규칙을 추가합니다.


iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

특정 출발지 IP 주소만 허용하는 규칙은 다음과 같습니다.


iptables -A INPUT \
  -p tcp \
  -s 192.168.10.100 \
  --dport 8080 \
  -j ACCEPT

하지만 규칙을 추가하는 것만으로 최종 정책을 판단해서는 안 됩니다. 기존 규칙의 순서, 기본 정책, 앞선 차단 규칙, 연결 추적 규칙 등을 함께 확인해야 합니다.


10.3 iptables와 nftables를 혼용하지 말아야 하는 이유

일부 배포판에서는 iptables 명령어가 nftables 기반 호환 계층으로 연결됩니다. 반면 레거시 백엔드를 사용하는 환경도 있습니다.

다음 명령어로 버전을 확인할 수 있습니다.


iptables --version

출력에 (nf_tables)가 표시된다면 nftables 기반 호환 인터페이스를 사용하고 있을 가능성이 높습니다.

그렇더라도 iptables 명령어와 nft 명령어로 관리되는 규칙의 관계를 실제 환경에서 확인해야 합니다. 운영 서버에서는 한 가지 관리 체계를 정하고, 그 체계를 기준으로 변경 이력을 관리하는 편이 안전합니다.



11. 방화벽 차단 문제를 tcpdump로 분석하기

서비스 접속 장애가 발생했을 때 방화벽 규칙만 확인하는 것으로는 부족할 수 있습니다.

가장 중요한 질문은 다음과 같습니다.

클라이언트가 보낸 패킷이 서버에 도착했는가? 그리고 서버는 어떤 응답을 했는가?


11.1 서버에서 TCP 8080번 패킷 확인

tcpdump -nn -i any 'tcp port 8080'

특정 클라이언트의 패킷만 보고 싶다면 다음과 같이 실행합니다.


tcpdump -nn -i any \
  'host 192.168.10.100 and tcp port 8080'

11.2 패킷 흐름별 해석

관찰 결과점검 방향SYN 패킷이 서버에 도착하지 않음클라이언트 경로, 중간 장비, 목적지 IP 확인SYN이 도착하지만 응답이 없음로컬 방화벽, 서비스 상태, 커널 처리 확인서버에서 RST 응답해당 주소·포트에서 대기 중인 서비스가 없는지 확인SYN-ACK가 나가지만 클라이언트에서 응답이 없음리턴 경로, 중간 방화벽, 클라이언트 측 확인TCP 연결이 성립한 뒤 HTTP 오류 발생웹 서버, 프록시, 백엔드 애플리케이션 확인

이 결과는 장애 원인을 좁히기 위한 단서입니다. 패킷 캡처만으로 방화벽 차단을 확정할 수 없는 경우도 있습니다.

예를 들어 SYN이 보이지 않는다면 서버 방화벽 때문일 수도 있지만, 패킷이 서버 인터페이스까지 도착하지 않는 다른 네트워크 문제일 수도 있습니다.


11.3 방화벽 규칙과 패킷 캡처를 함께 확인하기

다음 순서로 진행합니다.


1. 서비스 LISTEN 확인
       |
       v
2. 방화벽의 실제 적용 규칙 확인
       |
       v
3. 클라이언트에서 접속 재현
       |
       v
4. 서버에서 tcpdump 실행
       |
       v
5. SYN/SYN-ACK/ACK 흐름 확인
       |
       v
6. 필요하면 클라이언트에서도 캡처
       |
       v
7. 원인 계층을 좁힌 뒤 정책 변경

이 절차는 단순히 방화벽을 끄고 접속을 시험하는 것보다 안전하고 정확합니다.



12. 운영 서버에서 방화벽을 변경할 때 주의할 점

방화벽 변경은 서비스 접근성과 보안에 직접적인 영향을 줍니다.

특히 SSH로 원격 접속한 상태에서 잘못된 규칙을 적용하면 관리자 세션이 끊기거나 재접속이 불가능해질 수 있습니다.

변경 전에는 다음 사항을 확인해야 합니다.


  1. 현재 접속 중인 관리 IP 주소를 확인합니다.
  2. SSH 접속 포트와 적용 영역을 확인합니다.
  3. 기존 런타임 규칙과 영구 규칙을 각각 저장하거나 기록합니다.
  4. 변경할 규칙과 예상 영향을 문서화합니다.
  5. 가능하면 콘솔이나 대체 관리 경로를 확보합니다.
  6. 최소 범위의 규칙만 변경합니다.
  7. 변경 후 정상 접속과 차단되어야 할 접속을 모두 검증합니다.
  8. 문제가 발생하면 사전에 준비한 롤백 절차를 수행합니다.

현재 규칙을 파일로 보관하는 방법의 예시는 다음과 같습니다.


nft list ruleset > /root/nft-rules-before.txt

iptables 규칙을 사용하는 환경에서는 다음과 같이 기록할 수 있습니다.


iptables-save > /root/iptables-before.txt

firewalld의 런타임 및 영구 설정은 별도로 확인해야 합니다.


firewall-cmd --list-all-zones \
  > /root/firewalld-runtime-before.txt

firewall-cmd --permanent --list-all-zones \
  > /root/firewalld-permanent-before.txt

이 파일들은 현재 규칙을 기록하는 데 유용하지만, 그 자체가 자동 복구를 보장하는 것은 아닙니다. 복원 방법은 실제 방화벽 관리 체계와 운영 정책에 맞게 준비해야 합니다.

또한 방화벽 서비스 전체를 중지하는 방식으로 장애를 해결하려고 해서는 안 됩니다. 보안 정책을 우회하지 않고 문제가 되는 규칙을 좁혀서 수정하는 것이 원칙입니다.



13. 실전 점검 시나리오: 포트는 열려 있는데 외부 접속이 실패한다

상황은 다음과 같습니다.


  • 서버 IP: 192.168.10.50
  • 서비스 포트: TCP 8080
  • 클라이언트 IP: 192.168.10.100
  • 서버에서 애플리케이션은 실행 중

1단계: 서비스 상태 확인

ss -lntp '( sport = :8080 )'

LISTEN이 없다면 서비스 실행 상태와 설정을 확인합니다.


2단계: 로컬 접속 확인

curl -v --connect-timeout 3 http://127.0.0.1:8080/

로컬 접속이 실패하면 애플리케이션 또는 로컬 바인딩 문제부터 살펴봅니다.


3단계: 실제 IP로 접속 확인

curl -v --connect-timeout 3 http://192.168.10.50:8080/

루프백 주소로는 성공하지만 실제 IP에서는 실패한다면 바인딩 주소, 인터페이스 설정 등을 확인합니다.


4단계: firewalld 규칙 확인

firewall-cmd --get-active-zones
firewall-cmd --list-all

서비스가 사용하는 인터페이스가 어떤 영역에 연결되어 있는지 확인합니다.


5단계: nftables와 iptables 규칙 확인

현재 운영 환경에 맞는 명령어를 사용합니다.


nft list ruleset

또는 iptables를 사용하는 환경이라면 다음 명령어를 실행합니다.


iptables -L -n -v

두 명령어의 결과를 무조건 동일한 규칙 집합으로 간주해서는 안 됩니다. 실제 백엔드와 호환 계층을 확인해야 합니다.


6단계: 패킷 흐름 확인

tcpdump -nn -i any \
  'host 192.168.10.100 and tcp port 8080'

클라이언트에서 연결을 시도하면서 패킷이 도착하는지 확인합니다.


7단계: 필요한 규칙만 수정하고 검증

원인이 확인된 경우에만 해당 영역이나 규칙을 수정합니다. 변경 후에는 허용되어야 하는 연결뿐 아니라 허용되지 않아야 하는 연결도 테스트합니다.

운영 핵심: 방화벽 규칙을 변경하기 전에 원인을 확인하고, 변경 후에는 실제 패킷 흐름과 서비스 응답을 검증해야 합니다.



14. 핵심 정리

이번 편에서 기억해야 할 내용은 다음과 같습니다.


  • Linux 방화벽은 네트워크 패킷을 정책에 따라 허용하거나 차단합니다.
  • Netfilter는 Linux 커널의 네트워크 패킷 처리 기능과 관련된 프레임워크입니다.
  • nftables와 iptables는 방화벽 규칙을 관리하는 도구이며, 실제 연결 방식은 배포판과 설정에 따라 달라질 수 있습니다.
  • firewalld는 영역과 서비스, 포트를 중심으로 방화벽 정책을 관리합니다.
  • 런타임 규칙과 영구 규칙은 구분해서 확인해야 합니다.
  • 특정 IP만 허용하려면 기존의 전체 허용 규칙과 규칙 적용 순서까지 검토해야 합니다.
  • 포트가 열려 있어도 서비스 바인딩, 라우팅, 중간 방화벽, 애플리케이션 문제 때문에 접속이 실패할 수 있습니다.
  • tcpdump를 이용하면 패킷이 서버에 도착하는지와 서버가 어떤 응답을 하는지 분석할 수 있습니다.
  • 운영 서버에서는 방화벽을 무작정 중지하지 말고, 필요한 규칙만 안전하게 변경해야 합니다.

시스템 엔지니어에게 중요한 것은 명령어를 외우는 것이 아니라 현재 서버에서 어떤 방화벽 관리 체계가 사용되고 있는지 확인하고, 규칙과 실제 패킷 흐름을 연결해 원인을 분석하는 능력입니다.

다음 편에서는 NAT와 Port Forwarding을 다루겠습니다. 사설 IP 주소를 사용하는 서버가 외부 네트워크와 통신하는 원리, SNAT와 DNAT의 차이, 공유기와 Linux 서버에서 포트 포워딩을 설정할 때 발생하는 장애를 실전 관점에서 살펴보겠습니다.

다음 편은 네트워크 17편 — NAT와 Port Forwarding 완벽 이해입니다. SNAT·DNAT·MASQUERADE의 차이, 공유기 포트 포워딩과 Linux 서버의 패킷 흐름, tcpdump를 이용한 외부 접속 장애 분석까지 이어가면 네트워크 실무 과정이 자연스럽게 연결됩니다.

댓글

아직 댓글이 없습니다.

로그인 후 댓글을 남길 수 있습니다.