업스트림 VPN 뒤의 다운스트림 클라이언트: 라우트인가 NAT인가

게이트웨이 하나가 자기 기기를 위해 WireGuard를 돌리고 남의 네트워크로 OpenVPN 클라이언트를 연결한다. 두 내부 인터페이스 사이의 포워딩은 동작하므로 다운스트림 서브넷이 이제 업스트림 서비스의 일부라고 결론짓기 쉽다. 그렇지 않다. 클라이언트가 끌어온 라우트는 요청을 어디로 보낼지 게이트웨이에 알려 줄 뿐, 원격 네트워크가 들어 본 적도 없는 기기로 트래픽을 어떻게 되돌려 보내는지는 말해 주지 않는다. 규칙을 하나라도 추가하기 전에 업스트림이 실제로 지원하는 반환 모델을 고르라.

라우팅을 건드리기 전에 반환 모델을 정하라

이 설명에서 다운스트림 클라이언트는 10.90.0.0/24를 쓰고, 게이트웨이에 할당된 업스트림 터널 주소는 10.80.0.6, 승인된 원격 자원은 172.20.0.30이다. 이 형태에는 두 모델이 맞는다. 다운스트림 소스를 유지하고 먼 쪽이 그것을 라우팅하게 하거나, 소스를 게이트웨이 자신의 터널 주소로 변환하는 것이다. 이 결정 뒤의 모든 일은 기계적이며, 결정 자체에는 서비스 소유자가 필요하다. 위의 한 줄은 먼 쪽과의 라우팅 합의이고, 다른 한 줄은 혼자 할 수 있는 로컬 정책 변경이다. 이 둘을 혼동하는 것이 십 분짜리 변경을 협상으로 바꾼다.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

한 줄을 고르고 그것을 지켜라. 줄들은 단계가 아니라 대안이며, 섞으면 검토에서 아무도 설명할 수 없는 설계가 나온다.

라우팅으로 소스 유지

먼 쪽은 다운스트림 주소에서 요청을 받으므로 그 서브넷에 대한 지원되는 라우트와 peer 소유권, 그리고 그것을 받아들일 권한이 필요하다. 이는 원격 설정이며 어떤 로컬 Linux 라우트도 그것을 만들지 않는다. 프리픽스와 그것을 실어 나를 터널 peer를 함께 적어 명시적으로 문서로 요구하고, 답은 서비스가 사이트 간 구성 자체를 지원하는지에 달려 있다고 예상하라.

답이 그렇다면 로컬 설정은 작다. 포워딩을 켜고, 다운스트림 범위를 덮는 WireGuard peer의 allowed-ips를 두고, 양방향 통과를 허용하는 방화벽 정책을 둔다.

의도적인 소스 변환

서비스가 연결된 클라이언트 주소로만 트래픽을 되돌려 보낸다면 나갈 때 소스를 그 주소로 변환하고, 응답을 위해 되돌리는 conntrack 상태를 유지하라. 규칙은 의도한 다운스트림 소스, 의도한 원격 목적지, 업스트림 인터페이스로 한정하라. 모든 인터페이스에서 나가는 모든 것을 변환하는 규칙은 이 요구보다 훨씬 큰 정책이며 나중에 당신을 놀라게 할 것이다.

IPv6에는 자체 설계가 필요하다. IPv4 masquerade 줄을 복사하는 것은 아키텍처가 아니다. 변환된 경로는 캐시된 연결이 아니라 새 연결로 시험하라.

로컬 데이터 경로도 여전히 동작해야 한다

변환이 로컬 작업을 없애 주지는 않는다. 게이트웨이에는 여전히 다운스트림 목적지로 가는 라우트, 올바른 WireGuard peer 소스 소유권, 켜진 포워딩, 인터페이스 사이의 좁은 방화벽 정책이 필요하다. 게이트웨이 자체에서 만든 요청은 그 권한을 하나도 시험하지 않으므로 게이트웨이의 로컬 시험은 통과하지만 다운스트림 기기는 여전히 실패한다.

게이트웨이가 아니라 실제 다운스트림 기기에서 시험하라. 소스 주소가 이 연습의 전부다.

하나의 소스는 하나의 세션 정체성을 뜻한다

원격 서비스는 다운스트림 기기마다 독립된 인증이 아니라 게이트웨이의 인증된 세션과 그 변환된 주소를 본다. 기기별 권한과 애플리케이션 정체성을 명시적으로 유지하고, 여러 기기를 대신하는 게이트웨이가 애초에 허용되는지 서비스 소유자와 확인하라. 변환은 기기별 등록 요구를 우회하는 수단이 아니다. 서비스가 각 기기의 등록을 요구한다면 그 모델을 쓰거나 사이트 간 구성을 협상하라.

그 확인을 규칙 옆 runbook에 적어 두라. 다음 검토자가 그 설계가 승인된 것인지 아니면 그저 편리했던 것인지 물을 것이기 때문이다.

끊긴 상태를 정의한 다음 세 가지 요청을 시험하라

업스트림 터널이 끊길 때 무슨 일이 일어나는지 정하라. 허용된 원격 트래픽이 금지된 곳에서 평범한 WAN 대체 경로를 조용히 따라가서는 안 되므로, 통과를 허용하는 방화벽 정책도 닫힌 쪽으로 실패해야 한다. 그다음 실제 다운스트림 기기에서 세 경우를 시험하라. 허용된 요청이 동작하고, 금지된 요청이 실패하며, 업스트림 장애가 허용된 요청을 멈추는지.

규칙마다 한 줄로 롤백을 기록해, 의도를 다시 구성하지 않고도 변경을 되돌릴 수 있게 하라.