VPN 전용 iptables 호스트: tun 장치를 지정하세요, tun+가 아니라

-o tun+ 을 쓰는 것은 정확한 지시처럼 보이지만 실제로는 커널이 가진 모든 터널에 걸리는 와일드카드입니다. 두 번째 VPN 클라이언트, 컨테이너 브리지, 크래시한 세션이 남긴 인터페이스 모두 이를 만족하고, 호스트는 정책이 막으려던 트래픽을 허용하게 됩니다. 아래 절차는 장치 이름 하나를 고정하고, 터널이 실제로 만들어지도록 예외 순서를 정하며, 규칙이 잘못 들어갔을 때 돌아갈 길을 남깁니다. 각 단계는 따로 되돌릴 수 있을 만큼 짧습니다.

1단계: 지금 있는 규칙을 기록하세요

기본 정책을 바꾸기 전에 현재 상태를 저장해 롤백이 기억이 아니라 명령이 되게 하세요. iptables-save > /root/iptables.pre 은 모든 테이블을 복원할 수 있는 파일로 기록하고, 설정하려는 정책이 그 연결을 끊을 수 있는 상황에서 root 세션을 열어 둔 두 번째 터미널은 과잉 경계가 아닙니다. 원격에서 작업한다면 flush도 데드맨 스위치로 예약하세요.

다음으로 인터페이스를 나열하세요. 짐작한 이름은 원래 읽었어야 할 이름입니다: ip -br link 은 지금 존재하는 것을 보여 주고, 터널은 올라오기 전까지 나타나지 않습니다. 읽는 대로 장치 이름을 적어 두세요.

2단계: 터널에 고유한 이름을 주세요

OpenVPN 은 클라이언트 설정에서 dev tun_work 을 받아들이고, 그러면 Linux는 tun0 을 할당하는 대신 정확히 그 이름으로 인터페이스를 만듭니다. 다른 무엇도 그 이름을 차지하지 않는 한 재연결을 거쳐도 이름이 유지되며, 장치를 지목하는 규칙이 의미를 갖는 이유가 바로 이것입니다.

이름을 통제할 수 없다면 대신 터널 주소나 패킷 마크에 일치시키세요. 둘 다 동작하고, 둘 다 읽기 어렵고, 터널이 번호를 바꾸면 둘 다 더 조용히 실패합니다. 어느 쪽이든 한 가지에만 일치시키고 무엇인지 분명히 밝히세요.

3단계: endpoint 예외를 먼저 두고 정책을 쓰세요

VPN 전용 호스트는 짧은 예외 목록을 가진 기본 거부 호스트이며, 가장 중요한 예외는 터널이 존재할 수 있게 해 주는 것입니다. 터널 장치 규칙보다 endpoint 규칙을 앞에 두고 이 순서로 구성해야 핸드셰이크가 갈 곳이 생깁니다:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

endpoint의 실제 주소와 포트는 이 페이지가 아니라 여러분의 제공자 것입니다. endpoint가 호스트 이름이라면 한 번 해석해 결과를 고정하세요. 규칙은 이름을 조회할 수 없고, 돌아가는 응답은 다음 DNS 변경 뒤에 정책을 조용히 깨뜨립니다. 포트도 확인하세요. TCP 443으로 옮기는 제공자라면 아무도 적지 않은 규칙이 따로 필요해집니다. 프로토콜 하나에서만 동작하는 터널은 대개 방화벽 결함이 아니라 이 누락입니다.

라우터에서는 뒤쪽 클라이언트를 위해 같은 형태가 FORWARD 체인으로 들어가고, 라우터 자체 트래픽에는 자체 규칙이 필요합니다. 전달된 패킷만 덮는 규칙 집합은 SSH와 DNS를 예전 경로에 남겨 두며, 터널이 올라오는 순간 라우터가 도달 불가능해지는 이유가 이것입니다.

4단계: 존재만이 아니라 순서를 확인하세요

규칙은 순서대로 평가되므로 먼저 오는 ACCEPT는 나중에 추가한 REJECT를 그저 가립니다. established와 related 일치가 있어야 일반 인바운드 경로를 열지 않고도 자기 아웃바운드 요청에 대한 응답이 돌아옵니다. 이를 터널 수락 뒤에 두면 터널이 끊겨도 자기 인터페이스에서 반환 트래픽은 여전히 통과합니다.

규칙 수는 한 화면에서 읽을 수 있을 만큼 작게 유지하세요. 감사할 수 없는 규칙 집합은 맨 위에 예외를 덧붙여 임시로 고치게 되고, 기본 거부 정책이 서서히 기본 허용의 가장자리를 얻는 경로가 그것입니다. 변경 전후로 ACCEPT를 세어 보세요.

5단계: 부팅과 주소 체계를 넘겨 살아남게 하세요

손으로 넣은 규칙은 재부팅 때 사라지므로 배포판의 방화벽 서비스나 터널 인터페이스가 생긴 뒤 실행되는 유닛에서 불러오세요. OpenVPN이 시작되기 전에 도는 스크립트에서 tun_work 을 참조하는 것은 끊긴 트래픽의 부팅 루프를 만드는 흔한 방법입니다.

그다음 IPv6를 따로 확인하세요. IPv4용 기본 거부 정책이 좋아도 다른 주소 체계에 대해서는 아무 말도 하지 않습니다. ip -6 route 은 IPv4만 다루는 터널을 우회해 트래픽을 실어 나를 경로가 호스트에 있는지 알려 주고, ip6tables나 nftables에는 그에 맞는 규칙이 따로 필요합니다. 규칙 집합의 대칭을 믿지 말고 IPv6-only 목적지로 시험하세요.

6단계: 검증하고 복원할 준비를 하세요

터널을 올리고 의도한 서비스가 동작하는지 확인한 다음, 정책이 거부해야 할 것을 시험하세요. 답이 예상과 다르면 iptables-restore < /root/iptables.pre 로 복원하고, 그다음에야 규칙 편집을 시작하세요. 영속성과 검증된 복원 경로가 함께 있어야 이것이 두 번 할 수 있는 변경이 됩니다.