엔드포인트 주소가 바뀔 때의 VPN용 UFW 예외
킬 스위치는 어제의 피어를 여전히 통과시키는 반면 VPN 호스트 이름은 다른 곳으로 해석된다. UFW 예외를 소유자가 있는 하나의 워크플로로 새로 고친다.
클라이언트가 다시 연결을 시도하지만 머신 밖으로 아무것도 나가지 않는다. 같은 프로필이 지난주에는 동작했는데도 그렇다. 엔드포인트 호스트 이름이 이제 다른 주소로 해석되고, 아웃바운드 예외는 여전히 예전 주소를 가리킨다. 그 낡은 허용 하나만으로도 동작하던 킬 스위치가 완전한 단절로 바뀌며, 데스크톱이 보여 주는 어떤 상태 표시에도 그것은 드러나지 않는다. 복구는 한 줄 수정이 아니라 작은 워크플로다.
터널은 다시 연결되고, 그다음에는 아무것도 나가지 않는다
목적지 주소를 지정하는 아웃바운드 규칙은 한 시점의 스냅숏이지만 DNS 응답은 그렇지 않다. 제공자가 주소를 돌리면 클라이언트가 새 피어로 보내는 패킷은 어느 규칙과도 맞지 않아 기본 거부로 버려진다. 그러면 클라이언트는 시간 초과를 보고하고, 그것은 방화벽이 아니라 서버 문제처럼 보인다.
공개 조회가 돌려주는 주소를 고정하면 오늘은 되고 내일은 깨진다. 그것은 일회성 수정이지 유지보수 정책이 아니다.
실제로 의도하는 예외를 적어 보라
규칙에 필요한 네 가지 값을 먼저 적는다. 승인된 엔드포인트 이름이나 주소 집합, 전송 방식, 목적지 포트, 패킷이 나가는 인터페이스다. 네 가지 모두 허용의 일부이며, 그중 무엇이 틀려도 규칙은 그럴듯해 보인다. 셋이 맞는 규칙은 넷이 모두 틀린 규칙과 똑같이 실패한다. 명령을 입력하기 전에 적어 두어야 한다. 규칙은 그 뒤에 있는 설명만큼만 좋기 때문이다.
아래 명령은 유선 업링크에서 IPv4 UDP 엔드포인트 하나의 형태를 보여 준다. 두 값은 배포에 대해 확인한 값으로 바꾸라.
sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose
그 허용은 같은 포트의 임의 목적지를 허가하지 않고, 리스너를 만들지 않으며, TCP를 포함하지 않는다. UFW 매뉴얼 페이지는 주소와 인터페이스, 프로토콜이 규칙을 어떻게 좁히는지 설명하며, 바로 그 좁힘이 핵심이다.
하나의 워크플로로 새로 고친다
예외를 소유자와 전이가 있는 자원으로 다루라. 누군가 실행을 기억하는 명령으로 다루지 말라. 먼저 배포 자체의 리졸버와 엔드포인트 목록에서 후보를 얻고, 터널이 존재하기 전에 그 이름이 어떻게 해석될지 의도적으로 정하라. 그다음 규칙 집합을 건드리기 전에 후보를 의도한 프로토콜과 포트, 주소 계열에 대해 검증하라.
먼저 새 좁은 허용을 설치하고 그것이 로드되었는지 확인하라. 방화벽이 여전히 막는 주소를 쓰라고 요구하면 서버 장애처럼 보이는 실패가 나기 때문이다. 변경 중에는 무관한 규칙을 건드리지 말라.
클라이언트의 전이를 지원되는 재연결 경로로 관찰하고 어떤 원격 주소를 골랐는지 확인하라. DNS만 갱신하는 것으로는 기존 소켓이 이동하지 않으며, 엔드포인트 고정 설정은 레코드가 바뀐 뒤에도 클라이언트를 오래된 피어에 묶어 둘 수 있다.
마지막으로 낡은 허용을 의도적으로 폐기하라. 오래된 세션이 아직 살아 있는 동안에는 승인된 겹침 구간을 허용하라. 오래된 항목을 너무 일찍 지우면 짧은 단절이 생기고, 영원히 남기면 아무도 설명할 수 없는 허용이 남는다.
낡은 허용을 의도적으로 폐기하라
삭제가 위험의 대부분을 차지한다. 오래된 규칙이 지금 유일하게 동작하는 것이기 때문이다. 후보 설치가 실패했다면 계속하지 말고 아직 트래픽을 나르는 항목을 지우지 말라. 삭제 자체가 실패하면 정책을 최신이라고 선언하는 대신 낡은 허용을 낡은 것으로 기록하라.
업링크가 이더넷에서 Wi-Fi로 바뀔 때, 전송 방식이 바뀔 때, 또는 서비스가 여러 주소를 오갈 때 검토 전체를 다시 하라. 인터페이스에 특화된 규칙은 네트워크 변경 뒤에 일치를 멈추는 것이 맞으며, 그 동작은 퇴행처럼 보여도 옳다.
그다음 무해한 트래픽으로 계약을 입증하라. 승인된 엔드포인트는 설정 중에 도달 가능해야 하고, 보호된 애플리케이션은 연결된 뒤 동작해야 하며, 무관한 직접 트래픽은 장애 동안 차단된 채로 남아야 한다. 두 주소 계열과 의도적으로 실패한 갱신 시도 하나를 포함하라. 고정 주소를 한 번 수정한 뒤 성공하는 연결은 그 어떤 경우도 입증하지 못한다.