UFW 킬 스위치가 VPN을 막고 있나요? 피어를 허용하세요

체크리스트를 그대로 따랐습니다. 나가는 트래픽을 거부하고, 터널을 허용하고, ufw를 켰습니다. 그런데 클라이언트는 핸드셰이크에서 계속 기다리다 연결되지 않거나, 연결은 되지만 페이지가 하나도 열리지 않습니다. 두 실패는 같은 틈에서 나옵니다. 터널이 존재하도록 허용하는 규칙이 빠져 있습니다. 터널은 패킷이 빠져나가는 인터페이스가 아니기 때문입니다.

tun0에 대한 허용이 처음에는 아무것도 맞지 않는 이유

tun0은 세션이 생긴 뒤에 클라이언트가 만듭니다. 그 세션을 구성하는 데이터그램은 공급자의 1194 포트로 향하는 평범한 UDP 패킷이며, 물리적 출발 주소를 그대로 달고 wlan0이나 eth0으로 나갑니다. allow out on tun0 은 나가는 인터페이스가 tun0인 트래픽에만 맞으므로, 핸드셰이크 동안에는 아무것도 맞지 않습니다.

그 위에 default deny outgoing 를 얹으면 인터페이스가 나타나기도 전에 바깥 패킷이 버려집니다. 클라이언트는 다시 시도하고, 시간 초과가 나고, TLS나 핸드셰이크 실패를 보고합니다. 그러면 사람들은 인증서와 MTU를 뒤지기 시작하지만, 방화벽은 조용히 연결을 먹고 있습니다. 트래픽을 가두어야 할 규칙이 그 트래픽이 갇히는 것을 막고 있는 셈입니다.

반사적 수정은 누수를 영구화합니다. sudo ufw allow out on wlan0, 또는 기본값을 다시 허용으로 되돌리면 터널은 올라오지만 기계에는 킬 스위치가 남지 않습니다. 다음에 터널이 끊기면 모든 것이 물리 어댑터로 다시 흐릅니다. 저는 바로 그 두 편집 때문에 반나절을 잃었고, 그제야 내가 실제로 어떤 패킷을 거르고 있는지 알았습니다.

두 패킷 집합에 필요한 것

트래픽은 방화벽을 두 번, 두 가지 모양으로 지납니다. 안쪽 패킷은 터널 주소에서 tun0을 통해 밖으로 나갑니다. 바깥 패킷은 물리 주소에서 피어로 가며, 선로에서 보이는 것은 이것뿐입니다. 모양마다 규칙 하나씩입니다.

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

주소와 포트를 자신의 프로필에 있는 값으로 바꾸세요. WireGuard 피어는 보통 51820/udp로 응답합니다. TCP 443을 타는 OpenVPN 프로필은 대신 그 포트가 필요합니다. 세부는 달라도 모양은 같습니다. 두 규칙 모두 좁고, 함께 터널이 꺼진 동안 기계가 닿을 수 있는 유일한 목적지를 정의합니다.

순서는 두 번째 신화입니다. 순수 iptables라면 체인을 위에서 아래로 읽으며 어느 규칙이 이기는지 따집니다. ufw는 입력한 목록을 얇게 감싼 것이 아닙니다. 규칙을 자체 체인으로 컴파일하고 삽입 지점을 고릅니다. ufw status 은 ufw의 순서로 출력합니다, 여러분의 순서가 아니라. 규칙이 무시된 것처럼 보이면 다시 쓰기 전에 ufw show added 을 iptables -S | grep ufw 에서 컴파일된 집합과 비교하세요.

예외는 주소 하나 폭으로 남아야 합니다

피어 규칙은 클라이언트가 접속하는 주소를 지명하는 동안에만 옳습니다. 공급자는 엔드포인트를 돌리고, 호스트 이름을 해석하는 프로필은 DNS 변경을 따라 새 주소로 옮겨가지만 규칙은 옛 주소를 가리킨 채로 남습니다. 몇 달 동안 잘 돌던 터널이 올라오지 않으면, 무엇이든 넓히기 전에 규칙의 주소와 클라이언트가 찾는 주소를 비교하세요.

서브넷 전체로, 또는 1194 포트의 모든 목적지로 넓히면 정책은 다시 구멍 난 방화벽이 됩니다. 예외가 곧 킬 스위치입니다. 한 번 넓어지면 끌 것이 남지 않습니다. 주소 하나로 유지하고 어떤 프로필과 공급자에 속하는지 적은 주석을 남기세요. 반년 뒤에는 그 주소가 임의로 보일 테니까요.

이름 해석은 자기 줄을 가질 자격이 있습니다. 조회는 터널이 생기기 전에 물리 인터페이스를 통해 일어나므로, 엄격한 나가는 거부 정책은 클라이언트가 자기 서버를 찾지 못하게 만들 수 있습니다. 리졸버 주소로 가는 53 포트를 허용하거나, 한 번 해석해 주소를 프로필에 고정하세요. 모든 인터페이스에서 DNS를 허용하는 것은 결정이지 기본값이 아닙니다.

터널이 필요해지기 전에 정책을 세우세요

ufw enable 은 정책 전체를 한 번에 적용하고 체인을 다시 불러옵니다. 실행 중인 방화벽에서 기본 정책을 바꾸는 것도 체인을 다시 불러옵니다. ufw 매뉴얼 은 이것이 SSH 같은 기존 연결을 끊을 수 있다고 경고합니다. 그래서 명령은 이 순서로 갑니다. SSH 규칙을 활성화 앞에 두고 콘솔 세션을 열어 둔 채로요.

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset 은 그 블록에서 일부러 뺐습니다. 모든 규칙을 지우고 방화벽을 끄는 명령이며, 원격 호스트에서는 이어지는 활성화가 세션을 끊는 원인입니다. 그래도 초기화하겠다면 SSH 규칙을 추가하고, 더 나아가기 전에 콘솔로 돌아오는 두 번째 길을 확인하세요.

순서는 겉치레가 아닙니다. ufw가 도는 동안 추가한 규칙은 아무것도 비우지 않지만, 기본 정책을 뒤집는 순간 체인이 다시 불려 오고 옛 정책이 허용하던 세션도 함께 사라집니다. 기본값, 허용, 활성화를 한 번에 끝내세요. 기계에 의존하지 않는 들어갈 길이 아직 있을 때요.

차단 상태를 시험하고 되돌릴 수단을 남기세요

시험하지 않은 킬 스위치는 추측입니다. 클라이언트를 일부러 끊고 페이지를 열어 보세요. 실패해야 합니다. 다시 연결하면 규칙을 건드리지 않고도 회복되어야 합니다. sudo ufw status verbose 은 기본값과 기록 상태를 확인하고, ufw status numbered 은 목적을 넘긴 시험 규칙을 언제 지울지 보여 줍니다.

역방향 스크립트를 정방향 옆에 두세요. 나가는 거부와 죽은 터널을 가진 기계는 자기 수리를 내려받을 수 없으므로, 되돌리기는 디스크에 있어야 하고 콘솔에서 읽을 수 있어야 합니다.

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

터널이 이미 꺼져 있고 규칙을 걷어내야 할 때 실행하세요. 일상 단계가 아닙니다. 터미널을 닫기 전에 네 가지가 성립해야 합니다. 피어 규칙이 정확히 주소 하나를 지명하고, DNS에 이름 붙은 예외가 있고, 활성화가 허용 뒤에 왔고, 터널을 뽑으면 일반 트래픽은 죽지만 클라이언트는 영영 죽지 않습니다.