Onion 서비스와 VPN 서비스: 서로 다른 접속 모델

사람들은 Onion 서비스와 VPN으로만 닿는 서비스를 같은 발상, 즉 포트를 숨기고 비밀 주소를 공유한다는 발상의 두 가지 형태로 설명합니다. 둘은 주소가 무엇에 묶여 있는지, 누가 도달할 수 있는지, 요청이 오기 전에 무엇이 필요한지에서 다릅니다. 하나는 Tor 내부의 만남 지점이고, 다른 하나는 사설 네트워크 안의 경로입니다. 둘을 서로 바꿔 쓸 수 있는 것으로 다루면 사설도 아니고 유지 가능하지도 않은 설계가 됩니다.

신화: 두 설계 모두 그저 숨은 문

공통된 성질은 분명하지만 얇으며, 어느 설계도 관리 인터페이스를 직접 도달할 수 있는 공개 포트에 두지 않습니다. 그 뒤로는 모두 갈라집니다. Onion 주소는 서비스 자체의 키에서 나오므로 이름이 정체성에 묶이고, VPN 주소는 당신이 받아들여진 네트워크 안의 주소일 뿐입니다. 하나는 서비스를 덧씌운 계층 안에 숨기고, 다른 하나는 사설 토폴로지로 받아들입니다. 후자를 전자의 동의어로 보는 데서 혼란이 시작됩니다.

두 성질 모두 애플리케이션 자체에 대한 보안 통제가 아닙니다. 숨은 위치는 그 뒤의 소프트웨어를 고쳐 주지 않고, 사설 경로는 로그인 페이지에 인증을 더하지 않습니다. 두 설계 모두 여전히 앱 자체의 권한이 필요하고, 둘 다 여전히 업데이트와 복구를 책임질 사람이 필요합니다.

Onion 주소는 실제로 무엇을 가리키는가

v3 Onion 주소는 서비스의 공개 키를 부호화하므로, 아무도 자기가 통제하지 않는 서비스의 주소를 고를 수 없습니다. 클라이언트는 Tor를 거쳐 만남 지점에 연결하고, 서비스는 자기 쪽에서 같은 지점에 도달하며, 평범한 출구 노드가 그 연결을 서비스까지 나르지 않습니다. 이름은 정체성이며 DNS 레코드가 아닙니다.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

그래서 onion 이름을 위해 경로나 hosts 항목을 더해도 아무 소용이 없습니다. 이름 조회가 기제가 아니라 Tor 클라이언트와 그 회로가 기제입니다. 서비스가 소수 사람을 위한 것이라면 onion 클라이언트 인증이 연결을 받아들이기 전에 키를 요구할 수 있지만, 그것은 여전히 앱 로그인이 아닙니다. 주소를 공개하는 것도 의도적인 행위이며, 제한하지 않았다면 그것을 아는 누구나 연결을 시도할 수 있습니다.

onion 설계의 유일한 이유가 인증 설정을 피하는 것이라면 멈추십시오. 덮씌운 계층은 그것을 제공하지 않고, 결국 나중에 만들게 됩니다.

VPN 경로는 실제로 무엇을 주는가

VPN은 기기를 네트워크에 받아들이고 게이트웨이나 서브넷으로 가는 경로를 줍니다. 그 게이트웨이 뒤의 서비스는 터널 풀에서 온 주소를 보고 자기가 가진 권한을 적용합니다. 경로는 사용자가 누구인지 아무것도 말하지 않고, 말하는 것은 패킷이 어디로 갈 수 있는지입니다.

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

게이트웨이가 기기 상태를 강제할 수 있고 네트워크를 감사할 수 있으므로, 그 모델은 관리되는 기기를 가진 알려진 집단에 맞습니다. 익명이거나 일회성 방문자에게는 먼저 등록이 필요하므로 맞지 않습니다. 연결한 사용자가 무엇을 읽을 수 있는지는 여전히 앱 자체의 로그인이 정합니다. 도달 가능성을 허가와 혼동하면 VPN은 연결할 수 있는 모두에게 서브넷 전체를 주게 됩니다.

공개 범위가 불명하거나 계속 바뀜다면 멈추십시오. 한 페이지를 보여 주려고 낯선 사람을 사설 네트워크에 등록하는 것은 서비스를 공개하는 것에 버금가는 큰 약속입니다.

둘 중에서 고르기, 그리고 달라지지 않는 것

공개 범위가 기술자이고, 서비스에 공개 주소를 전혀 두면 안 되고, Tor 클라이언트 요건을 받아들일 수 있다면 onion 모델을 고릅니다. 공개 범위가 당신이 관리하는 기기를 가진 특정 집단이고 그 접근을 네트워크 계층에서 기록하려면 VPN 모델을 고릅니다. 어느 선택도 앱 인증, 패치 적용, 복구 경로의 필요를 없애지 않습니다. 어느 쪽도 사용자에게 중요한 의미에서 자동으로 더 사설적이지 않습니다.

두 설계 모두에서 누가 서비스에 도달할 수 있는지, 어떻게 식별되는지, 자격 증명을 잃으면 무슨 일이 생기는지 적어 두십시오. onion 서비스의 답에는 클라이언트 인가 키와 주소 자체가 들어갑니다. VPN의 답에는 계정, 기기, 게이트웨이 정책이 들어가며, 이것들은 서로 다른 목록이므로 다음 관리자에게 분명한 것은 그중 하나뿐입니다.

비교는 애플리케이션이 시작되는 곳에서 끝납니다. 숨은 주소와 사설 경로는 전송의 선택이고, 요청에 무엇을 허용할지는 앱이 정해야 합니다. 그 결정을 별도 문서에 두면 어느 설계도 다른 쪽의 일을 조용히 흡수하지 않습니다.