TAP인가 TUN인가? Android OpenVPN 클라이언트와 브리지 서버

노트북에서 동작하는 프로필이 휴대폰에서는 실패한다. 분명한 조치는 클라이언트 설정에서 한 단어를 바꾸는 것이다. 그 단어는 도움이 되지 않는다, 양쪽 끝이 같은 종류의 트래픽을 말하고 있지 않기 때문이다.

TAP은 이더넷 프레임을 나른다. TUN은 IP 패킷을 나른다. Android VPN 앱에는 IP 인터페이스가 주어지며, 이는 설정이 무엇이라 말하든 두 배치 중 하나만 가능하게 한다.

비교는 짧지만, 휴대폰에서 고칠 수 있는지 아니면 서비스를 바꿔야 하는지를 결정한다.

서로 다른 페이로드를 가진 두 종류의 터널

TAP 인터페이스는 이더넷 어댑터처럼 동작한다. 프레임을 나르므로 ARP, 브로드캐스트, 그리고 IP 아래에서 LAN이 나르는 모든 것을 포함한다. 이것이 브리지를 가능하게 한다 — 터널이 브로드캐스트 도메인을 확장하고, 클라이언트는 스위치에 연결된 것처럼 동작한다.

TUN 인터페이스는 자신에게 주소 지정된 IP 패킷을 나른다. 협상할 링크 계층도, ARP도, 브로드캐스트도 없다. 무엇이 터널로 들어가는지는 라우팅이 결정하고, 서버 쪽 설정은 브리지 대신 서브넷을 쓴다.

양쪽 끝은 둘 중 무엇을 하는지에 합의해야 하지만, 한쪽에서 dev tap을 dev tun로 바꾼다고 서비스가 전환되지는 않는다. 라우팅된 터널을 기대하는 클라이언트와 여전히 프레임을 보내는 서버가 생기고, 핸드셰이크는 성공해도 쓸모 있는 것은 아무것도 지나가지 않는다.

Android가 앱에 실제로 주는 것

플랫폼의 VpnService API는 앱에 주소, 경로, MTU로 구성되는 IP 패킷용 가상 인터페이스를 준다. 그 API에는 이더넷 어댑터가 없고, 앱이 그것을 만들어 낼 방법도 없다.

그래서 OpenVPN Connect는 Android에서 TAP 브리지가 아니라 라우팅된 TUN 연결 지원을 문서화한다. Android FAQ는 이 경계에 대한 클라이언트 측 진술이며, 플랫폼 API와 일치한다.

root 권한 네트워크 도구, 사용자 정의 펌웨어, 또는 명시적 변환 계층을 구현한 제품은 다른 배치다. 일반적인 경우는 이것을 전제로 계획해야 한다 — 파일을 가져와 일반 사용자로 실행되는 앱이며, IP 인터페이스가 있고 그 아래에는 아무것도 없다.

그래도 시도하면 어떻게 보이는가

연결은 대개 성립한다. 그래서 실패가 혼란스럽다 — 클라이언트는 연결되었다고 보고하고, 서버 로그에는 피어가 나타나며, 어떤 애플리케이션도 동작하지 않는다.

휴대폰에 할당된 주소로 보낸 트래픽은 도착하지 않는다, 서버가 휴대폰이 한 번도 가진 적 없는 MAC 주소로 프레임을 브리지하기 때문이다. 브로드캐스트에 의존하는 검색은 비어 있다. LAN이 브리지를 통해 DHCP에 의존한다면 휴대폰은 그렇게 임대를 받지 못하고, 브리지된 서브넷에서 수동으로 지정한 주소도 빠진 인터페이스를 만들어 주지 않는다.

일부 클라이언트는 더 일찍, 프로필 가져오기에서 실패한다, 구현할 수 없는 장치 유형을 볼 때. 두 동작은 같은 의미이고, 경로를 추가하거나 DNS를 바꾸거나 터널의 주소 범위를 넓혀도 어느 쪽도 고쳐지지 않는다.

서버 쪽이 바꿔야 할 것

수정은 VPN 서비스를 운영하는 쪽의 몫이고, 보통 마이그레이션이 아니라 추가다. 라우팅된 장치, 자체 클라이언트 서브넷, 주소를 할당하고 휴대폰에 필요한 경로를 밀어 주는 서버 쪽 설정을 갖춘 두 번째 OpenVPN 인스턴스를 실행한다. 기존 브리지 인스턴스는 이더넷이 정말 필요한 장치를 계속 서비스한다.

실무에서 작동하게 하는 두 가지 세부가 있다. LAN에는 새 클라이언트 서브넷을 위한 반환 경로가 필요하고, VPN 호스트를 가리켜야 한다, 그렇지 않으면 응답이 영원히 돌아오지 않는다. 그리고 터널 호스트의 방화벽은 터널 인터페이스와 LAN 사이를 전달해야 하며, 호스트 자체에서 한 테스트가 성공할 때 가장 자주 빠지는 단계가 이것이다.

운영자가 서비스를 추가할 수 없다면 대안은 브리지에 참여할 수 있는 장치, 즉 휴대폰을 대신해 동작하는 노트북이나 라우터다. 그것은 자체 관리 비용이 드는 우회책이지 Android 설정이 아니다.

터널이 아니라 애플리케이션에서 결정하라

휴대폰이 실제로 무엇에 도달해야 하는지 물은 뒤 그것을 매핑하라. 이름이나 주소로 도달하는 파일 공유나 인트라넷 사이트는 IP 요구 사항이고, DNS가 이름을 풀고 경로가 있으면 라우팅된 터널이 그것을 충족한다. 로컬 브로드캐스트 도메인을 훑는 검색 도구는 IP 요구 사항이 아니며, 라우팅을 아무리 더해도 채워지지 않는다.

그 표가 바로 보낼 요청이다. 애플리케이션, 그것이 쓰는 주소나 이름, 그리고 검색에 의존하는지 여부를 밝혀라. 운영자는 그 설명으로 행동할 수 있지만, 연결되지 않는 휴대폰에 대해서는 아무도 그럴 수 없다.

마지막으로, 모든 클라이언트가 LAN 어댑터를 흉내 내게 하는 대신 필요한 장치를 위해 TAP 서비스를 유지하라. 목적이 분명한 두 서비스가 모두에게 반쯤 동작하는 하나보다 지원하기 쉽다.