UFW의 before.rules에서 VPN NAT를 어디에 두고 어떻게 테스트할까

셸에 입력하면 작동하는 NAT 규칙도 before.rules에 붙여 넣으면 실패합니다. 그 파일은 스크립트가 아니기 때문입니다. 이 파일은 테이블 섹션, 체인 선언, 각 테이블의 COMMIT 표시가 있는 복원 형식 문서입니다. 잘못된 위치의 줄은 복원 전체를 중단시키거나 있다고 믿었던 규칙을 조용히 버립니다. 아래 절차는 프레임워크가 기대하는 위치에 조각을 두고 다음 다시 로드 전에 결과를 증명합니다.

셸 명령은 복원 파일이 아니다

iptables -t nat로 시작하는 줄은 iptables 바이너리에 대한 지시이고, UFW가 읽는 파일은 완전한 규칙 집합의 설명입니다. 차이는 겉모습이 아닙니다. 복원 형식은 어느 테이블에 있는지, 어떤 체인이 존재하는지, 테이블이 어디서 끝나는지 알아야 합니다. 그 문서에 붙여 넣은 명령은 구문 오류거나, 더 나쁘게는 잘못된 테이블에 붙은 규칙입니다. 프레임워크가 이 파일들을 복원 도구로 불러오는 이유는 바로 이들이 순차적이 아니라 선언적이기 때문입니다.

문서는 전체로 로드되므로 잘못된 섹션 하나가 나머지 적용을 막을 수 있습니다. 그래서 NAT 조각의 작은 실수가 필터 규칙까지 함께 무너뜨리고, 이렇게 방화벽 변경이 장애가 됩니다.

기존 테이블 섹션 안에 조각을 넣는다

NAT 조각에는 모양이 있고, 모양은 그 안의 규칙 텍스트보다 중요합니다. 테이블 헤더가 섹션을 열고, 체인 선언이 카운터를 세우고, 규칙이 따르고, COMMIT이 섹션을 닫습니다.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

위의 풀과 인터페이스는 여러분 값의 자리 표시자입니다. 복사할 가치가 있는 부분은 구조입니다. 파일에 이미 *nat 섹션이 있으면 두 번째를 여는 대신 그 섹션 안에 규칙을 추가하세요. 형식은 테이블마다 COMMIT 하나를 기대하며, 같은 테이블에 두 섹션이 있으면 곧 일어날 수리를 기다리는 것입니다. 배포판의 체인 정의를 그대로 유지하고, 공급업체가 자체 통합을 위해 추가한 것도 포함하세요. UFW 프레임워크 매뉴얼은 before, user, after 파일과 일치하는 COMMIT 요구 사항을 문서화합니다.

파일이 비어 있다면 튜토리얼로 채우지 마세요. 어떤 패키지가 소유하는지, 실제 라이브 정책이 무엇인지 확인하세요. 빈 영구 파일은 커널에 규칙이 없다는 것을 증명하지 않고, 로드된 규칙 집합은 다음 다시 로드에 완전한 파일이 있다는 것을 증명하지 않습니다. 먼저 지원되는 기준선을 복원한 다음 그 위에 사이트 변경을 다시 적용하세요.

적용하지 않고 후보를 테스트한다

복원 도구는 적용하지 않고 규칙 집합을 파싱하고 구성할 수 있으며, 이것이 가장 저렴한 테스트입니다. 라이브 파일이 아니라 보호된 사본에 대해 실행하고, 종료 상태만이 아니라 오류 텍스트를 읽으세요. 파싱 실패는 줄과 보통 테이블을 지목하므로 실패한 다시 로드가 알려주는 것보다 많습니다.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

그 검사를 통과하는 것은 문서가 파싱된다는 것만 증명하고 그 이상은 아닙니다. 후보가 UFW가 의존하는 모든 체인을 여전히 포함하는지, 의도한 소스만 허용하는지, 원격 관리가 계속 도달 가능한지는 증명하지 않습니다. 이들은 별도의 검토이며, 마지막 것은 시작 전에 여는 두 번째 세션에 걸맞습니다.

설치된 백엔드와 주소 패밀리에 맞는 도구를 고르세요. 호환성 계층을 통해 nft 백엔드를 실행하는 호스트에는 해당 명령이 필요하고, IPv6 규칙은 전혀 다른 파일에 있습니다.

포워딩, NAT, 액세스 정책을 분리한다

소스 변환은 주소 지정 문제를 해결할 뿐 아무것도 허용하지 않습니다. 포워딩은 sysctl과 필터 테이블이 제어하는 별도의 권한이며, 터널이 경로를 잡지만 트래픽이 통과하지 않을 때 사람들이 잊는 것입니다. 액세스 정책은 어떤 소스가 어떤 서비스에 도달할 수 있는지에 대한 세 번째 결정이고, 어떤 NAT 규칙도 그것을 표현하지 않습니다. 이 셋을 분리해 두는 것이 하나의 모호한 증상 대신 진단 가능한 장애로 만듭니다.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

이 세 출력은 하나씩이 아니라 함께 읽으세요. 포워딩이 꺼진 masquerade 규칙은 연결은 되지만 아무 데도 도달하지 못하는 클라이언트를 만들며, 클라이언트 쪽에서는 정확히 라우팅 결함처럼 보여 사람들을 잘못된 파일로 보냅니다. 필터 테이블은 너무 넓은 accept가 숨는 곳이기도 하므로, 거기 있는 동안 기본 정책도 확인하세요.

다시 로드, 거부, VPN 손실을 검증한다

세 가지 관찰이 완전한 인수 테스트를 만듭니다. 다시 로드가 성공하고, 허용된 클라이언트 작업이 작동하며, 거부되어야 할 요청이 실제로 거부되는 것입니다. 세 번째가 건너뛰는 것이며, 정책이 무엇인가를 하고 있다는 유일한 증거입니다.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

다음으로 설계한 실패를 시험하세요. 터널을 내리고 호스트가 무엇을 하는지 보세요. VPN이 켜져 있는 동안만 작동하는 정책은 선언되지 않은 의존성을 가진 정책이기 때문입니다. 그런 다음 한 번 더 다시 로드하여 남은 실행 상태가 아니라 파일이 작동하는 결과를 만든다는 것을 증명하세요.

IPv4 NAT는 IPv6에 대해 아무 말도 하지 않으므로, 규칙과 같은 메모에 두 패밀리의 의도된 범위를 적으세요. 목표는 일관된 관리 정책이며, 우연히 파싱된 조각은 그 증거가 아닙니다.