휴대폰만 VPN 밖에? 라우터 터널 아니면 기기별 클라이언트

노트북은 VPN에 연결돼 있고 휴대폰도 같은 Wi-Fi에 있는데, 휴대폰은 여전히 ISP 주소로 접속한다. 이것은 클라이언트 버그가 아니다. 터널은 그것을 끝내는 기계 위에 살고, 가까이 있다고 해서 다른 기기가 물려받지는 않는다. 적용 범위는 라우터가 직접 클라이언트를 돌릴 때, 또는 기기를 의도적으로 LAN의 게이트웨이로 만들 때만 넓어진다. 어떤 모델을 원하는지는 세 가지로 정해진다. 공급자가 실제로 말하는 프로토콜, 기기마다 얼마나 다르게 다뤄야 하는지, 그리고 밤 아홉 시에 어떤 장애를 감당할 수 있는지.

라우터 터널이 실제로 덮는 범위

터널이 라우터에서 끝나면 그를 지나 라우팅되는 모든 기기가 같은 출구를 공유한다. TV, 콘솔, 또는 클라이언트를 절대 돌리지 않을 기기에 대한 매력이 바로 이것이다. 설치할 것도, 계속 갱신할 것도 없고, 공급자를 바꾸는 곳도 한 곳뿐이다.

적용 범위에는 사람들을 놀라게 하는 조건이 붙는다. 게스트 네트워크나 자체 정책을 가진 두 번째 SSID는 그 정책이 정한 경로를 따르지 터널을 따르지 않는다. IPv6 경로는 IPv4만 나르는 터널을 우회할 수 있다. 자체 VPN 앱이나 자체 암호화 리졸버를 가진 기기는 라우터를 완전히 무시한다. 그리고 라우터 자체의 트래픽은 업데이트와 DNS를 포함해 자체 출력 정책을 따르는데, 이것은 LAN의 전달 트래픽과 다른 경로다.

확인은 두 모델 모두 같고 일 분이면 된다. 두 기기에 세상이 보는 주소가 무엇인지 물은 다음 라우터의 연결 목록에서 터널을 본다. 휴대폰이 ISP 주소를 보고하는데 라우터가 이미 맺어진 터널을 보여 준다면, 휴대폰은 그 터널로 라우팅되지 않는 것이고, 다시 연결한다고 달라지지 않는다.

기기별 클라이언트가 이기는 지점

요구가 갈라지는 순간 기기별 클라이언트가 이긴다. 업무용 노트북은 휴대폰이 들어가면 안 되는 회사 터널이 필요할 수 있고, 공급자 클라이언트는 앱 단위 분할 터널을 제공할 수 있는데 라우터는 그것을 표현하지 못하며, 콘솔은 NAT 유형을 지키려고 밖에 남아야 할 수 있다. 기기마다 따로 실패하기도 하므로 구독 하나가 만료됐다고 집 전체가 조용해지지는 않는다.

자격 증명이 더 날카로운 논점이다. 모든 사람을 대신해 연결하는 라우터는 계정 하나를 들고 있고, 그 네트워크의 모든 사람이 그 접근 권한을 물려받는다. 인터넷 접속 전에 사람마다 인증하려는 것이라면 라우터 터널만으로는 안 된다. 흔한 설계는 계정을 검증한 뒤 클라이언트를 이미 맺어진 터널로 들여보내는 캡티브 포털인데, 이는 대부분의 가정이 원하는 것보다 움직이는 부품이 많다.

프로토콜 지원이 선호보다 많은 경우를 가른다

소비자용 라우터는 제조사가 실어 보낸 프로토콜만 노출한다. PPTP, L2TP, 또는 평범한 IPsec만 있는 라우터는 OpenVPN이나 WireGuard 프로필만 배포하는 공급자에 연결할 수 없고, 어떤 설정으로도 바뀌지 않는다. 정직한 선택지는 지원되는 프로토콜을 말하는 공급자, 필요한 클라이언트가 있는 OpenWrt나 다른 펌웨어를 쓰는 라우터, 또는 기기마다의 클라이언트다.

반대 경우도 흔하다. OpenVPN이 가능한 라우터라도 자체 클라이언트와 자체 라우팅 요령에 의존하는 공급자에는 쓸 수 없으므로, 하드웨어를 사기 전에 공급자의 지원 프로토콜 페이지를 읽고 펌웨어 버전을 확인하라(제품 페이지의 WireGuard 지원은 흔히 특정 펌웨어 세대를 뜻한다).

WireGuard 클라이언트가 있는 여행용 라우터는 라우터 모델의 저가판이고, 클라이언트를 돌릴 수 없는 몇몇 기기에 대한 합리적인 답이다. 그래도 라우터 터널이므로 게스트 네트워크, IPv6, 공통 실패에 관한 위의 내용은 그대로 적용된다.

세 번째 선택지: 기기 하나를 게이트웨이로

노트북에서 클라이언트를 공유하는 것은 가능하고, 노트북을 라우터로 만들었다고 할 때 사람들이 보통 뜻하는 것이 이것이다.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

이것은 기기가 잠들거나, 클라이언트가 다른 프로필로 다시 연결하거나, 기기 자체 방화벽이 전달 패킷을 버릴 때까지 동작한다. 그러면 뒤에 있는 모든 것이 한꺼번에 연결을 잃고, 장애는 VPN 문제가 아니라 죽은 네트워크처럼 보인다.

실험실이나 임시 구성에는 괜찮다. 영구 구성으로 쓰면 노트북 한 대가 집안의 단일 장애점이 되고, 보통 덮개를 닫자 TV가 왜 멈췄는지 누군가 궁금해하는 것으로 끝난다.

들어오는 포트, DNS, 그리고 함께 지는 실패

들어오는 서비스는 터널을 따라 움직인다. 라우터의 VPN은 보통 LAN 서버의 포트 포워딩을 깨뜨리고, 서비스를 터널로 접근해야 한다면 동적 DNS 이름은 ISP 주소가 아니라 VPN 출구를 가리켜야 한다. 어떤 공급자는 라우팅 가능한 들어오는 주소를 아예 주지 않는데, 그것에 기대던 계획은 조용히 끝난다.

라우터가 터널을 소유하면 DNS는 라우터를 따르는데, 한 기기가 다른 리졸버를 필요로 할 때까지는 편하다. 기기별 클라이언트는 그것을 표현할 수 있지만 라우터 정책은 네트워크를 둘로 쪼개지 않고는 못 한다. 실패도 공유되어, 한 번의 크래시, 한 건의 만료된 구독, 또는 한 개의 잘못 밀어 넣은 경로가 같은 순간에 모든 기기를 끊는다.

기기가 클라이언트를 돌릴 수 없고 출구 하나로 충분하다면 라우터 모델을 고른다. 정책이 다르거나, 공급자가 라우터에 없는 프로토콜을 요구하거나, 계정을 공유하면 안 된다면 기기별 클라이언트를 고른다. 기기가 게이트웨이라면 어느 인터페이스가 어느 네트워크를 공유하는지 적어 두고 '터널 끊김' 상황을 시험하라. 이런 설계 대부분이 바로 그 상태에서 틀렸다는 것이 드러난다.