OpenWrt VPN 존, 포워딩, 매스커레이딩: 무엇이 필요할까

VPN이 OpenWrt를 만날 때마다 세 가지 변경이 뒤섞입니다. 포트를 여는 것, 포워딩을 허용하는 것, 매스커레이딩을 켜는 것입니다. 이들은 서로 다른 질문에 답하며 보통 그중 하나만 실제 요구 사항입니다. 각 제어를 그것이 관장하는 트래픽 역할에 따라 읽으면 추측이 결정으로 바뀌고, 변경이 잘못되었을 때 어떤 증상을 예상해야 하는지도 알려 줍니다. 기억나는 체크박스가 아니라 실패한 역할의 이름부터 붙이세요.

제어를 건드리기 전에 트래픽 역할을 이름 붙이세요

존 입력은 라우터 자체에 무엇이 도달할 수 있는지 결정합니다. 존 출력은 라우터가 스스로 만드는 트래픽을 다루고, 존 포워딩은 존을 통과하는 트래픽의 기본값이며, 매스커레이딩은 나갈 때 출발지 주소를 다시 쓸지 결정합니다. 이는 네 가지 다른 질문이고, 존 정책은 같은 값으로 네 가지 모두에 한 번에 답하므로 존 전체를 바꾸는 것은 거친 도구입니다. 이름 붙인 규칙은 나머지를 건드리지 않고 그중 하나에 답할 수 있습니다.

쓸모 있는 지도는 트래픽 역할별인데, 무언가 실패했을 때 관찰할 수 있는 것이 바로 그것이기 때문입니다. 아래의 각 역할에는 그것을 결정하는 제어 하나와 그것을 가리키는 증상 하나가 있습니다:

라우터에서 수신하는 쪽에는 좁은 입력 규칙 하나면 충분합니다

라우터의 OpenVPN 서버는 라우터로 주소 지정된 트래픽을 받으므로, 그 외부 연결은 그것을 운반하는 존의 입력 정책에 달려 있습니다. 구성된 전송 방식과 포트를 허용하고 그 존의 다른 모든 것은 거부로 두세요. 포트 규칙 하나는 존 전체 허용보다 훨씬 작은 변경이며, 일 년 뒤에도 설명할 수 있는 것은 바로 그것입니다.

그 규칙을 유지하기에 안전하게 만드는 두 가지가 있습니다. 첫째는 서비스가 실제로 쓰는 포트를 이름으로 지정한다는 점이고, 둘째는 존 정의 옆에 있어서 다음 사람이 왜 존재하는지 볼 수 있다는 점입니다. 아래 줄은 형태일 뿐이고 포트는 서버에 구성된 값을 대신하는데, 옛 포트에 남은 규칙은 감사 전까지 보이지 않으므로 서비스가 옮겨가면 두 곳 모두에서 그 포트를 바꾸세요.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

다시 불러오기 전에 검증하세요. 방화벽 파일의 구문 오류는 라우터를 동작하는 규칙 집합 없이 남길 수 있습니다. fw4를 쓰는 릴리스에서 검사는 별도 명령이며, 망가진 블록을 조용히 받아들이는 대신 큰 소리로 실패합니다. 검사가 통과된 뒤에만 다시 불러오고, 이전 파일은 되돌릴 수 있는 곳에 보관하세요.

fw4 check
service firewall reload

클라이언트 요청은 입력이 아니라 포워딩을 지납니다

인증 후 LAN 서비스를 요청하는 터널 클라이언트의 요청은 포워딩된 흐름을 만들므로, 그것을 결정하는 제어는 터널 존과 LAN 존 사이의 포워딩 관계입니다. 터널 인터페이스를 원하는 존에 할당한 다음 방향, 출처, 서비스를 선언하세요. 존 할당이야말로 포워딩 규칙에 의미를 주는 것이며, 둘은 함께 읽어야만 이해됩니다. 터널 존을 출발지로, LAN 존을 목적지로 지정하는 포워딩 관계는 하나의 의도적인 결정으로 읽히지만, 존 전체의 허용 두 개는 사고로 읽힙니다.

라우터 자체에 도달하는 것은 여전히 입력 경로를 쓰므로, 게이트웨이로 보내는 ping은 그 뒤의 파일 공유에 대해 아무것도 말해 주지 않습니다. 그 두 실패는 서로 다른 블록에 살고 서로 다른 변경으로 고칩니다. 둘 중 하나를 바꾸기 전에 두 경로를 따로 적어 두세요.

매스커레이딩은 라우팅 결정이지 허가가 아닙니다

매스커레이딩은 선택된 나가는 트래픽의 출발지 주소를 다시 씁니다. 먼 쪽에 돌아올 경로가 없는 출구 설계를 구할 수 있고, 주소를 기록하거나 주소로 인가하는 모든 서비스에서 개별 클라이언트 주소를 숨깁니다. 이것을 끄는 것은 돌아올 경로에 관한 라우팅 선택이지, 안쪽 구멍을 닫는 보안 스위치가 아닙니다. 변환이 켜져 있을 때 동작하고 끄는 순간 실패하는 터널은 보통 돌아올 경로가 빠진 것이지 방화벽 규칙이 빠진 것이 아닙니다.

라우팅된 대안은 변환 대신 먼 쪽에 돌아올 경로를 필요로 합니다. 어느 선택지도 방화벽 허가나 애플리케이션 계정을 제공하지 않으므로, 매스커레이딩을 끄는 것은 아무 데도 도달하지 못하는 터널 클라이언트를 거의 고치지 못합니다. IPv4와 IPv6 정책도 따로 다루세요. 변환 설정 하나가 두 계열을 모두 설명하지는 않습니다.

허용된 요청과 거부된 요청으로 결정을 증명하세요

허용되어야 할 요청 하나와 거부되어야 할 요청 하나를 보낸 다음, 각 결정을 내린 제어를 확인하세요. 우연히 로드된 페이지는 증거가 아니라, 증거는 일치한 규칙이며 그것이 일치한 체인 안에 있습니다. 거부는 모든 것이 허용된 것이 아니라 정책이 무언가를 하고 있음을 보여 주므로 성공만큼 중요합니다.

현재 릴리스에서는 두 명령이 그 증거를 줍니다. 요청이 받아들여지면 일치한 규칙의 카운터가 움직이고, 그 규칙에 로깅을 켜 두었다면 로그가 드롭을 보여 줍니다:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

방화벽 정책을 바꾸기 전에 아직 쓸 수 있는 관리 경로를 유지하고, 구성 소유자의 검증 및 롤백 절차를 따르세요. 라우터에서 잠그는 변경은 테스트 결과가 아니라 두 번째 사고입니다. 관찰할 때마다 존과 트래픽 역할을 옆에 기록하여, 결과 쌍이 행운의 페이지 로드를 묘사하는 대신 정책을 설명하게 하세요.