Nftables의 리눅스에서 포트를 열기 전에 규칙을 확인하십시오.

외부에서 보면 포트가 닫힌 것처럼 보이지만, 그러다가 애플리케이션이나 라우터 쪽으로 확인하게 됩니다. 무엇을 수정하기 전에 nftables에 의해 실제로 로드된 규칙을 확인하세요. /etc/nftables.conf 파일은 활성 상태와 다를 수 있으며, 로컬 방화벽만으로는 전체 네트워크 경로를 설명할 수 없습니다.

이 방법을 사용하면 ruleset을 읽고, 수신 트래픽을 처리하는 체인을 찾아 세션을 잃지 않고 수정 사항을 테스트할 수 있습니다. 원격으로 작업할 경우 두 번째 연결을 열어 두십시오.

로드된 방화벽을 읽는 것으로 시작하세요

다음 명령은 아무것도 변경하지 않습니다. 현재 커널에 있는 테이블, 체인, 규칙 및 가능한 카운터를 표시합니다:

sudo nft list ruleset

출력이 길면 먼저 테이블을 나열하고 관심 있는 테이블에 초점을 맞추세요:

sudo nft list tables
sudo nft list table inet filter

inet 패밀리는 IPv4와 IPv6 규칙을 포함할 수 있습니다. 테이블은 ip, ip6, bridge 또는 netdev에 속할 수도 있습니다. 문제를 해결했다고 해서 IPv6 규칙을 IPv4 규칙으로 대체하지 마십시오.

필터링 테이블에서는 type filter hook input으로 기본 체인을 특히 찾으세요. 이 체인이 대상 머신으로의 트래픽을 수신합니다. 이 줄의 policy drop은 accept 규칙이 없는 패킷이 거부됨을 의미합니다.

나중에 특정 규칙을 삭제해야 할 경우 유용한 규칙 식별자를 보려면 -a를 추가하세요:

sudo nft -a list chain inet filter input

input, forward 및 output을 혼동하지 마세요. SSH 연결을 수신하는 서버는 일반적으로 input을 사용합니다. 다른 호스트로 트래픽을 라우팅하는 머신은 forward에서 패킷을 차단할 수 있습니다. 인터넷으로 나가는 애플리케이션은 output을 통과합니다.

포트 및 규칙 순서 확인

체인의 규칙은 순서대로 평가됩니다. 거부 규칙이 포트 허용 이전에 배치되면 우선권을 가집니다. 프로토콜, 포트 및 연결 상태를 확인하세요:

sudo nft list chain inet filter input
sudo ss -lntup

SSH의 경우, 기대되는 규칙은 보통 tcp dport 22 accept와 비슷하게 보입니다. 데몬이 다른 곳에서 수신 대기하는 경우 포트가 다를 수 있습니다. ss -lntup의 출력은 프로그램이 실제로 예상된 포트와 주소에서 수신 대기하고 있는지 확인합니다. 열린 방화벽은 정지된 서비스를 사용할 수 없도록 하지 않습니다.

또한 ct state established,related accept 규칙과 루프백 인터페이스 iif lo accept도 확인하세요. 이는 이미 설정된 연결에 대한 응답과 로컬 트래픽의 손상을 방지합니다. ruleset에 카운터가 포함되어 있으면, 연결 테스트 전후에 비교하여 어떤 규칙이 트래픽을 보고 있는지를 알아보세요.

거부된 경우 머신 외부에 문제가 있을 수 있습니다: 클라우드 보안 그룹, 라우터, NAT 리디렉션, VLAN, 기업 방화벽 또는 127.0.0.1에만 연결된 서비스일 수 있습니다. 다른 컴퓨터에서 nc -vz 서버_주소 22로 포트를 테스트하거나 SSH 클라이언트를 사용해 보세요. 서버에서 nftables에 손대기 전에 ss로 수신 대기를 확인하십시오.

실제로 차단하는 규칙 식별

체인은 jump 또는 goto로 다른 체인을 호출할 수 있습니다. 따라서 포트 허가는 표시된 첫 번째 체인에서 반드시 보이지 않습니다. 체인 호출, 명명된 집합 및 로깅 프리픽스가 있는 규칙을 다시 확인하세요. counter drop 또는 reject 유형의 규칙이 포트 이전에 있을 경우 결과를 설명하는 경우가 많습니다.

대상 패킷을 nft monitor trace로 추적할 수 있지만, 이 명령은 활성 머신에서 많은 데이터를 생성합니다. 진단의 짧은 창을 위해 사용하고 주소나 포트로 트래픽을 필터링하는 임시 규칙을 설정하세요. 그 다음 nft -a list ruleset로 표시된 핸들과 함께 규칙을 제거하십시오.

폭넓은 추적 또는 로깅 규칙을 외부 서버에 남기지 마십시오. 이는 로그를 채우거나 진단에 잡음을 추가할 수 있습니다. 첫 번째 점검으로 체인 카운터와 다른 컴퓨터에서 테스트하는 것으로 충분할 때가 많습니다.

활성 ruleset과 지속 파일은 다를 수 있습니다

nft list ruleset는 활성 상태를 읽습니다. 규칙을 로드한 서비스가 무엇인지 또는 재시작 후 어떤 파일이 다시 로드될 것인지 알려주지 않습니다. Debian 및 Ubuntu에서는 일반적으로 /etc/nftables.conf와 서비스 상태를 확인하세요:

sudo systemctl status nftables
sudo systemctl is-enabled nftables
sudo grep -nE '^(table|include|flush)' /etc/nftables.conf

firewalld, UFW, Docker 또는 호스팅 도구를 사용하는 배포판에서는 여러 구성 요소가 규칙을 작성할 수 있습니다. 다른 서비스가 이미 이를 관리하고 있다면 튜토리얼에서 본 ruleset을 /etc/nftables.conf에 복사하지 마십시오. 먼저 머신에서 선언된 관리자를 식별하고 재로드 후 규칙을 다시 확인하십시오.

명령줄로 추가된 규칙은 다음 재시작 또는 서비스 재로드 시 대개 사라집니다. 반대로, 지속 파일을 수정해도 로드되지 않는 한 변경되지 않습니다. 이는 포트가 열려 있다고 결론짓기 전에 양쪽을 확인하는 이유입니다.

규칙을 적용하기 전에 백업하고 테스트하십시오

쓰기 작업 전 현재 상태를 보관하십시오. 백업 파일은 관리자만 읽을 수 있도록 유지해야 합니다:

sudo install -m 600 /dev/null /root/nftables-before-change.nft
sudo nft list ruleset | sudo tee /root/nftables-before-change.nft > /dev/null

그 다음, 임시 파일에서 수정을 준비하세요. nft -c는 규칙을 로드하지 않고 구문을 확인합니다:

sudo nft -c -f /etc/nftables.conf

이 검증은 새로운 ruleset이 여러분을 허용할 것이라는 것을 증명하지 않습니다. SSH 세션을 하나 더 연결하고 첫 번째 세션에서 파일을 적용한 후, 다른 터미널에서 새로운 연결을 시도하세요. 접근이 끊어지면 비상 세션을 통해 백업을 복원할 수 있습니다:

sudo nft -f /etc/nftables.conf
sudo nft list ruleset
# 중단되거나 잘못된 규칙의 경우:
sudo nft -f /root/nftables-before-change.nft

원격 서버에서 단독으로 flush ruleset 명령을 실행하지 마십시오. 이는 교체 파일을 확인하기 전에 현재 모든 규칙을 제거합니다. 전체적으로 검증된 파일을 로드한 후 즉시 활성 ruleset을 점검하세요.

수정 후 확인 작업

sudo nft list ruleset를 다시 실행하고 예상된 테이블과 체인이 여전히 존재하는지 확인하세요.
실제로 사용된 포트에서 다른 머신으로 서비스 테스트하세요.
포트가 여전히 접근 불가능하면 sudo ss -lntup를 확인하세요.
인입된 패킷을 로깅하는 규칙이 있다면 sudo journalctl -k -b로 커널 로그를 확인하세요.
재시작 후, nftables 서비스가 배포판의 지속 파일을 제대로 로드하는지 확인하세요.

간단한 경우에는 리눅스에서의 UFW에 대한 기사가 더 적합합니다. 방화벽을 수정하기 전에 서비스의 가용성을 진단해야 한다면, ss를 통해 열린 포트를 확인하세요. 문서 nft(8)는 패밀리, 체인 및 -c 옵션에 대한 세부 정보를 제공합니다.