스마트폰 VPN으로 집에 연결하기: 방화벽을 인터넷 출구로 만들기

스마트폰을 집 터널에 연결하고 LAN 파일 공유를 여는 것은 터널이 작동한다는 증거다. 스마트폰의 인터넷 요청이 집을 통해 나간다는 증거는 아니다. 이 두 결과의 차이는 전달 정책과 경로이지, 스마트폰의 체크박스 하나가 아니다. 대부분이 이미 설정했다고 믿는 차이이기도 하다.

세 가지 결정이 출구 경로를 만든다. 스마트폰이 터널로 무엇을 보내는지, 집 게이트웨이가 그것을 어디로 전달하는지, 터널이 없을 때 무슨 일이 일어나는지이며, 각각은 스마트폰 화면에서는 다른 것과 똑같아 보이는 실패 모드를 가진다.

두 번의 홉, 두 가지 정책

바깥 연결은 집 VPN 리스너에서 끝난다. 안쪽 패킷은 어딘가로 전달해야 하는 별개의 객체이며, 전달은 터널을 애초에 받아들이는 것과 다른 방화벽 결정이다.

phone app -> encrypted tunnel -> home listener
          -> decrypted packet -> forward policy -> home uplink -> destination

일반적인 가정용 라우터에서 이들은 서로 다른 규칙 집합에 산다. 터널을 받아들이는 것은 VPN 인터페이스의 입력 정책이고, 스마트폰 트래픽을 인터넷으로 내보내는 것은 전달 정책에 업링크가 필요로 하는 소스 변환을 더한 것이다. 터널을 받아들이고 아무것도 전달하지 않는 라우터는 연결됨으로 표시되지만 어떤 페이지도 로드하지 않는 스마트폰을 만든다.

VPN 서비스가 집 안의 별도 기계에서 실행된다면 홉이 하나 늘어난다. 이제 라우터는 그 기계에서 오는 트래픽을 보므로, 규칙은 스마트폰의 터널 주소가 아니라 서버 주소에 적용되고, 소스 변환은 모든 스마트폰을 하나의 호스트처럼 보이게 할 수 있다.

리스너는 필터가 아니다

필요한 정보가 아직 존재하는 동안 집행이 어디서 일어나는지 결정하라. 라우터에서는 스마트폰의 터널 주소가 보이고 직접 일치시킬 수 있다. 두 번째 변환 뒤에서는 사라지고, 스마트폰 주소를 위해 쓴 규칙은 조용히 아무것과도 일치하지 않는다.

정책이 노트북에는 통하고 스마트폰에는 통하지 않는 흔한 이유다. 노트북은 라우터에 직접 연결되고, 스마트폰은 라우터를 통해 전달하는 서버에 연결되며, 규칙이 기대하는 주소를 보존하는 것은 첫 번째 경로뿐이다. 규칙이 틀린 것이 아니라, 그 지점에 더 이상 존재하지 않는 값과 일치시키고 있는 것이다.

각 집행 지점에서 보이는 소스 주소와 함께 경로를 적어 두라. 그 도표 하나가 어떤 규칙을 편집하기 전에 이런 사례의 대부분을 해결한다.

스마트폰이 실제로 보내야 하는 것

집 서브넷으로 가는 경로만 받는 스마트폰은 그 서브넷의 트래픽만 터널로 보낸다. 나머지는 모두 모바일 네트워크로 나가므로 파일 공유는 작동하고 인터넷 요청은 집에 도달하지 않는다.

전체 터널 커버리지는 클라이언트 측 라우팅 결정이며, 설치되는 프로필에서 가정하지 말고 플랫폼이 지원하는 방식으로 설정해야 한다. 설정된 뒤에는 VPN 서버 자체로 돌아가는 경로가 터널 밖에 있어야 하며, 그렇지 않으면 클라이언트는 자체 전송을 유지할 수 없다.

DNS는 별도의 결정을 받을 자격이 있다. 나머지 트래픽에서 가장 벗어나기 쉬운 부분이기 때문이다. 프로필의 리졸버 주소는 클라이언트가 다르게 처리하는 제안이며, 자체 암호화 리졸버를 가진 앱은 완전히 별개의 경로를 탈 수 있다. 집 정책이 쿼리가 특정 리졸버에 도달하는 데 의존한다면, 트래픽이 실제로 지나가는 곳에서 강제하거나 일부 쿼리는 그러지 못한다는 점을 받아들여라. 당신의 리졸버를 우회하는 쿼리는 그것을 위해 쓰인 규칙에 결코 도달하지 않는다.

IPv6는 부록이 아니라 DNS와 같은 문단에 속한다. 전체 IPv4 터널은 AAAA 트래픽에 대해 아무것도 말하지 않으며, 이중 스택 모바일 네트워크의 스마트폰은 그것을 위해 기본 경로를 기꺼이 사용할 것이다. 전달인지 차단인지 명시적으로 선택하라.

방화벽이 볼 수 있는 것과 볼 수 없는 것

게이트웨이는 집행 지점이 드러내는 것에 대해 작동할 수 있다. 주소, 포트, 프로토콜, 인터페이스, 연결 메타데이터다. 전달된 HTTPS 요청은 집 터널을 지난다는 이유만으로 페이지 본문이나 비밀번호를 넘겨주지 않는다.

이 한계를 말할 가치가 있다. “방화벽으로 통과시켜라”라는 표현은 가정용 라우터가 하는 것보다 많은 검사를 암시한다. 목적지 규칙, DNS 정책, 애플리케이션 계층 프록시는 서로 다른 세 가지 통제이며 배포 비용도 세 가지로 다르다.

집 LAN 클라이언트용으로 구성된 기능이 VPN 인터페이스에도 적용된다고 가정하지 마라. 영역 구성원 자격은 구성 선택이며, 올바른 영역에 있지 않은 VPN 인터페이스는 소파에서 시험한 어떤 규칙도 물려받지 않는다.

연결 해제 상태를 결정하라

터널을 사용할 수 없을 때 스마트폰은 모바일 네트워크로 되돌아가거나 트래픽 전송을 거부한다. 둘 다 합리적이며, 대부분이 구성했다고 믿는 것과 일치하는 것은 하나뿐이다.

폴백은 편리하고 정의상 누출되는데, 터널이 떨어지는 순간이 요청이 통신사 경로로 나가는 순간이기 때문이다. 차단은 더 강력하며 스마트폰을 집에 도달할 수 있는지에 의존하게 만들고, 이는 여행자에게 실제 가용성 비용이 된다. 어느 행동도 버그가 아니며 둘 다 제품이고, 말하든 말든 당신은 그 사이에서 선택하고 있다.

가정하지 말고 선택을 시험하라. 집 서비스를 멈춘 뒤 스마트폰 브라우저에서 요청 하나, 백그라운드에서 도는 앱에서 요청 하나를 시도하라. 나중에 다시 연결해도 이미 나간 요청은 되돌아오지 않는다.

스마트폰 자체에서 두 가지 통제된 점검으로 마무리하라. 집을 통과해야 하는 허용된 작업 하나와, 집 정책이 시행해야 하는 거부 하나다. 재연결 후 게이트웨이가 기대한 흐름을 기대한 주소 패밀리에서 기록했는지 확인하라. “연결됨”을 표시하는 스마트폰은 그 검증의 시작이며, 결코 끝이 아니다.