설정할 수 없는 NAT 뒤의 VPN: 여전히 작동하는 것

모든 터널 끝점에는 상대방이 도달할 수 있는 주소와 포트가 필요하며, 관리하지 않는 라우터가 그 요구 사항이 실패하는 흔한 이유다. 흥미로운 점은 우회 기법이 존재한다는 것이 아니라, 각 기법이 클라이언트에서 보이지 않는 매핑 테이블의 속성에 의존한다는 것이다. 그중 두 속성이 거의 모든 것을 결정한다. 매핑이 어떻게 생성되는지, 그리고 내부가 한 번도 접촉하지 않은 주소에서 오는 패킷을 받아들이는지다. 환경을 이 속성들로 분류하면 우회 기법은 더 이상 전설이 아니다.

매핑 테이블이 모든 것을 결정한다

네트워크 주소 변환은 내부 주소와 포트를 공인 주소와 포트에 대응시켜 기록하는 테이블을 유지한다. 기록과 일치하는 응답은 역변환되고, 일치하는 기록이 없는 외부 패킷은 목적지가 전혀 없다. 이 단일 동작이 라우터 뒤의 리스너가 인터넷에서 도달할 수 없는 이유를 설명한다. 또한 각 방향의 첫 패킷이 내부에서 시작되어야 하는 이유도 설명한다.

라우터 쪽에서 테이블을 보면 우회 기법이 분명해진다. 무언가가 영구 항목을 만들거나, 임시 항목을 만들어 신선하게 유지하거나, 트래픽이 그 경로를 전혀 지나지 않는 경우다. 이 글의 나머지는 이 세 경우를 순서대로 다룬다. 여기서 어떤 것도 테이블이 기록하는 것 이상의 벤더 기능에 의존하지 않는다.

랑데부 서비스가 할 수 있는 일과 없는 일

UDP 홀 펀칭은 필터를 이기는 대신 아웃바운드 기록을 임시 개구부로 사용한다. 두 피어가 랑데부 서비스에 접속하면, 서비스는 각 공인 끝점을 학습하고 상대방에게 그 끝점을 알려준다. 그러면 양쪽이 서로를 향해 전송하고, 각 아웃바운드 패킷이 응답을 안으로 들여보내는 기록을 만들거나 갱신한다. 순서가 작동하게 만들고, 순서가 취약하게 만든다. 상대가 기록을 만들기 전에 전송하는 피어는 그냥 버려지지만, 잠시 뒤 재시도는 성공한다. 서비스 자체는 VPN 트래픽을 나르지 않으므로 유일한 지렛대는 조정하는 타이밍이다.

매핑 동작이 나머지를 결정하며, RFC 4787 은 세 가지 형태를 말한다. 끝점 독립, 주소 의존, 주소 및 포트 의존이다. 마지막 형태에서는 피어가 겨냥해야 할 포트가 목적지마다 바뀌므로 예측이 더 이상 신뢰할 수 없다. 여기서 이 기법은 막다른 길을 만난다. 통신사급 NAT와 엄격한 기업 방화벽은 모두 기법이 필요로 하는 예측 가능성을 없애고, 아무리 재시도해도 되돌아오지 않는다.

Keepalive, 재부팅, 그리고 움직이는 끝점

뚫린 경로는 리스너가 아니라 흐름이므로 그 위에서 도는 모든 것은 변화를 견뎌야 한다. 주기적 트래픽으로 매핑을 살아 있게 유지하고, 공인 끝점이 움직이는 것을 감지하고, 라우터가 재부팅되거나 주소가 재할당된 뒤 다시 설정해야 한다. 메시 VPN 제품은 그 논리를 자체 제어 평면에 두지만, 평범한 서버는 그것을 여러분에게 맡긴다. Keepalive는 같은 매핑이 살아 있는 동안만 도움이 되고, 모바일 클라이언트에서는 배터리를 소모하므로 공격적인 간격은 무료가 아니다.

한 시간 잠든 노트북은 보통 다른 공인 끝점으로 돌아온다. 경로를 다시 설정하는 것은 다시 내부에서 실행되어야 하며, 이는 같은 요구 사항을 클라이언트에 되돌린다.

빠진 포워딩을 우회하는 세 가지 방법

첫 번째 방법은 기능이 있고 켜져 있을 때 라우터가 직접 항목을 만들도록 요청하는 것이다. UPnP IGD, NAT-PMP, PCP를 통한다. 두 번째는 공인 주소를 가진 릴레이에 트래픽을 넘기는 것으로, 항상 작동하고 항상 대역폭과 다른 신뢰 경계를 대가로 치른다. 세 번째는 방향을 뒤집는다. 내부 호스트가 공인 서버로 아웃바운드 터널을 열고 나머지 전부가 그 안에서 이동한다.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

릴레이 끝점은 그 거래를 클라이언트 구성에서 보이게 한다. 끝점이 피어 자신의 주소가 아니라 릴레이인 것이다. 영구 keepalive는 매핑을 따뜻하게 유지하고, 허용된 접두사는 클라이언트가 그 너머로 무엇을 보낼 수 있는지 결정한다. 내부 호스트에서 시작하는 역방향 터널 은 소유자만 다른 같은 발상이며 NAT 변경이 전혀 필요 없다. 세 가지 모두 내부에서 시작되는 트래픽이므로, 설계상 원치 않는 트래픽을 차단하는 방화벽을 이기지 않고도 인바운드 요구 사항을 없앤다.

우회 기법을 라우터 소유자에 맞추라

라우터를 관리한다면 정적 UDP 포워딩이 어떤 펀칭 기법보다 감사하기 쉽고, 눈에 보이는 방식으로 실패한다. 관리하지 않는다면 벤더가 릴레이나 호스팅 제어 평면을 제공하는지, 정책이 그 사용을 허용하는지 확인하라. 둘 다 없다면 남은 선택은 역방향 터널이거나 끝점이 외부에서 도달 불가능하다는 사실을 받아들이는 것이다. 어느 것을 썼는지 기록하는 것은 들리는 것보다 중요하다. 선택지마다 누가 트래픽을 관찰할 수 있는지, 제삼자가 무언가를 바꿀 때 무슨 일이 일어나는지가 다르기 때문이다.

최종 경로가 직접이었는지 릴레이를 거쳤는지 기록하라. 그 한 가지 사실이 지연 시간과 장애 동작을 모두 예측한다. RFC 4787은 그 모든 아래의 매핑 동작에 대한 참조로 남아 있으며, 그 매핑 절을 읽는 것이 세 가지 우회 기법을 차례로 시험하는 것보다 빠르다. 테이블은 어떤 선택을 했는지 관심이 없다. 다음 패킷이 무엇을 할 수 있는지만 기록한다.