일부 연결 문제는 사용 중인 앱으로 인해 발생하지 않습니다. 장치 간 네트워크 경로에서 발생합니다.
집 Wi-Fi에서는 통화가 즉시 연결되지만 호텔 Wi-Fi에서는 어려움을 겪는 경우, 게임 로비가 한 플레이어에게는 작동하고 다른 플레이어에서는 실패하는 경우 또는 모바일 데이터에서 사무실 네트워크로 전환한 후 개인 정보 보호 도구가 다르게 작동하는 경우 이러한 현상을 발견할 수 있습니다. 일반적인 이유 중 하나는 여러 장치가 하나의 공용 인터넷 주소를 공유할 수 있게 해주는 네트워크 주소 변환 계층인 NAT입니다.
이 기사에서는 NAT 순회가 무엇인지, UDP 홀 펀칭이 존재하는 이유, 릴레이 폴백이 유용해지는 경우, VPN Satelites 독자가 이러한 개념을 마법 보장이 아닌 연결 컨텍스트로 처리해야 하는 이유를 설명합니다.
NAT가 일상적인 네트워크에서 수행하는 작업
대부분의 사람들은 사설 네트워크에 대해 생각하지 않고 사용합니다. 노트북, 휴대폰, 태블릿, TV가 모두 하나의 라우터 뒤에 있을 수 있습니다. 집 안의 각 기기에는 고유한 개인 주소가 있습니다. 더 넓은 인터넷에서는 하나의 공개 주소를 공유하는 것처럼 보이는 경우가 많습니다.
그 번역이 유용하네요. 이는 네트워크가 공용 IPv4 주소를 보존하고 일반 홈 라우팅을 관리 가능하게 유지하는 데 도움이 됩니다. 그러나 이는 또한 실질적인 문제를 야기합니다. 라우터가 들어오는 트래픽이 어디로 가야 하는지 알지 않는 한 네트워크 외부의 장치는 일반적으로 네트워크 내부의 장치에 대한 직접 연결을 열 수 없습니다.
일반적인 웹 브라우징의 경우 일반적으로 괜찮습니다. 장치는 외부 연결을 시작하고 라우터는 매핑을 기억하며 응답은 해당 임시 경로를 통해 돌아옵니다. 특히 UDP를 통해 더 직접적으로 통신하기 위해 두 개의 엔드포인트가 필요한 앱의 경우 상황을 예측하기 어려울 수 있습니다.
이것이 NAT 순회를 위한 기본 설정입니다.
NAT 순회란 무엇입니까?
NAT 통과는 하나 또는 두 개의 엔드포인트가 NAT 뒤에 있는 네트워크를 통해 애플리케이션이 통신하는 데 도움이 되는 기술의 일반적인 이름입니다.
평범한 영어로 이 앱은 “라우터가 주소를 변환하고 들어오는 트래픽을 필터링하더라도 이 두 장치가 서로 작동하는 경로를 찾을 수 있습니까?”라는 실용적인 질문에 대답하려고 합니다.
NAT 동작이 다양하기 때문에 하나의 보편적인 대답은 없습니다. IETF RFC 4787와 같은 표준은 UDP에 대한 NAT 동작을 설명하고 멀티미디어 통신 및 온라인 게임과 같은 실시간 앱에서 일관성이 중요한 이유를 설명합니다. 통화, 공동 작업 도구, 게임, 원격 액세스 도구, P2P 스타일 시스템 및 VPN와 같은 앱은 모두 네트워크가 트래픽을 처리하는 방식에 영향을 받을 수 있습니다.
VPN Satelites 리더의 경우 유용한 점은 간단합니다. 연결이 네트워크에서 다르게 동작하는 경우 라우터 동작, 캐리어 등급 NAT, 방화벽 정책, 패킷 필터링, 혼잡 또는 기타 경로 조건을 반영할 수 있습니다. 하나의 앱 설정이 깨졌다는 증거로 자동으로 읽어져서는 안 됩니다.
UDP 홀펀칭이란?
UDP는 연결 지향 트래픽과 관련된 일부 지연 및 오버헤드를 피할 수 있기 때문에 실시간 애플리케이션에서 자주 사용됩니다. 그러나 UDP는 많은 사람들이 전통적인 연결을 상상하는 것과 같은 방식으로 오래 지속되는 세션을 생성하지 않습니다.
UDP 홀 펀칭은 두 엔드포인트가 각각 아웃바운드 UDP 패킷을 보내 해당 NAT 장치가 임시 매핑을 생성하는 NAT 통과 기술입니다. 타이밍과 NAT 동작이 일치하면 상대방의 트래픽이 해당 매핑을 통해 돌아올 수 있습니다.
문구는 공격적으로 들리지만 개념은 이름에서 알 수 있는 것보다 더 평범합니다. 아웃바운드 및 반환 트래픽에 대한 라우터의 기존 규칙을 사용하여 작업하는 것입니다. Bryan Ford, Pyda Srisuresh 및 Dan Kegel의 기초 연구에서는 홀 펀칭이 UDP 기반 애플리케이션에서 사용되는 실용적인 접근 방식으로 설명하는 동시에 주요 제한 사항도 강조합니다. 모든 NAT 설정에서 탐색 기술이 작동하지 않습니다.
그 제한이 중요합니다. 일부 네트워크는 유용한 방식으로 매핑을 재사용합니다. 다른 사람들은 특정 대상에 더 좁게 연결된 매핑을 만듭니다. 일부 네트워크는 NAT 위에 방화벽 동작을 추가합니다. 일부 모바일 및 ISP 네트워크에서는 사용자가 업스트림 변환 레이어를 전혀 제어하지 않는 캐리어급 NAT 뒤에 사용자를 배치합니다.
따라서 누군가 UDP 홀 펀칭이 무엇인지 묻는다면 간단히 대답하면 다음과 같습니다. 이는 응용 프로그램이 NAT 생성 매핑을 통해 직접 UDP 경로를 시도하는 방법입니다. 신중한 대답은 다음과 같습니다. 다양한 환경에서 잘 작동할 수 있지만 보장되는 것은 아닙니다.
직접 연결이 때때로 실패하는 이유
다음과 같은 몇 가지 일반적인 이유로 직접 연결이 실패할 수 있습니다.
- 앱이 다른 대상에 접속할 때 라우터는 동일한 외부 포트 매핑을 재사용하지 않을 수 있습니다.
- 네트워크는 들어오는 UDP 패킷을 다른 네트워크보다 더 엄격하게 필터링할 수 있습니다.
- 캐리어급 NAT 레이어는 사용자와 공용 인터넷 사이에 위치할 수 있습니다.
- 직장, 학교, 호텔 또는 행사장 네트워크는 자체 정책에 따라 트래픽을 제한할 수 있습니다.
- 모바일 네트워크는 신호 품질이나 네트워크 연결이 변경됨에 따라 경로가 변경될 수 있습니다.
- 보안 제품이나 로컬 방화벽에 의해 트래픽이 앱에 도달하기 전에 차단될 수 있습니다.
이러한 경우 중 어느 것도 사용자가 자신이 제어할 수 없는 규칙을 우회하려고 시도해야 한다는 의미는 아닙니다. 실용적인 점은 연결 동작이 단일 앱 기본 설정 이상에 따라 달라진다는 점을 이해하는 것입니다. 네트워크가 의도적으로 트래픽 유형을 차단하거나 제한하는 경우 일반적으로 올바른 다음 단계는 허용된 네트워크를 사용하거나, 서비스 약관을 확인하거나, 네트워크 관리자에게 문의하는 것입니다.
릴레이 폴백이 적합한 곳
직접 연결이 불안정할 경우 일부 시스템에서는 릴레이를 사용합니다. 두 끝점 모두 외부로 중간 서버에 연결되고 서버는 둘 사이에 트래픽을 전달합니다. IETF RFC 5766는 특정 NAT 상황에서 직접 피어 통신이 불가능할 때 릴레이 지원 통신을 위한 프로토콜로 NAT 주변의 릴레이를 사용한 횡단의 약자인 TURN를 설명합니다.
릴레이는 직접 NAT 탐색과 다른 문제를 해결합니다. 두 장치 모두 릴레이 서비스에만 연결하면 되므로 릴레이를 사용하면 연결 가능성이 향상될 수 있습니다. 단점은 트래픽이 추가 경로를 사용하므로 대기 시간, 대역폭 비용 및 운영 복잡성이 추가될 수 있다는 것입니다.
이것이 바로 많은 연결 설계가 직접 경로를 먼저 시도한 다음 필요할 때 폴백하는 것을 선호하는 이유입니다. IETF RFC 8445는 ICE를 STUN 및 TURN 개념을 사용하여 가능한 경로를 검색하고 테스트하는 UDP 기반 통신을 위한 NAT 탐색을 위한 표준 추적 접근 방식으로 설명합니다. 그렇다고 모든 VPN 관련 도구가 ICE, STUN 또는 TURN를 사용한다는 의미는 아닙니다. 이는 단순히 일반적인 엔지니어링 패턴을 보여줍니다. 즉, 어떤 경로가 작동하는지 테스트한 다음 직접 연결을 사용할 수 없는 경우 폴백을 사용합니다.
독자들에게 중요한 교훈은 현실적인 기대 설정입니다. 릴레이 폴백은 직접 경로가 실패한 상황에서 연결을 가능하게 할 수 있지만 모든 네트워크 상태를 사라지게 하는 것과는 다릅니다.
VPN Satelites 독자에게 이것이 의미하는 바
VPN Satelites 콘텐츠는 개인 정보 보호, 연결, 인터넷 라우팅 및 사용자 기대와 같은 주제와 관련된 경우가 많습니다. NAT 순회는 앱 주변의 네트워크가 앱 자체만큼 중요할 수 있는 이유를 설명하기 때문에 동일한 교육 환경에 속합니다.
이 주제에서는 제품 연결을 적당한 수준으로 유지하는 것이 중요합니다. 이 기사는 VPN Satelites가 특정 NAT 통과 방법, 릴레이 아키텍처, 포트 전달 설정, 고정 IP 옵션 또는 프로토콜 스택을 사용한다고 주장하지 않습니다. 여기서의 가치는 실용적인 이해력입니다. 용어를 이해하면 문제 해결 지침을 더 주의 깊게 읽고 VPN 관련 앱이 모든 네트워크 규칙을 재정의할 것이라고 예상하지 않고 연결 문제를 평가하는 데 도움이 됩니다.
연결이 불안정한 경우 몇 가지 위험도가 낮은 검사를 통해 앱 동작과 네트워크 동작을 분리하는 데 도움이 될 수 있습니다.
- 홈 Wi-Fi와 모바일 데이터 등 허용되는 다른 네트워크를 사용해 보고 문제가 앱에서 발생하는지 아니면 네트워크에서 발생하는지 확인하세요.
- 로컬 라우터를 제어했는데 정상적인 연결 성능이 저하된 것으로 나타나면 로컬 라우터를 다시 시작하세요.
- 네트워크를 관리하는 직장, 학교, 호텔, 행사장, 트래픽 제한이 있는 ISP 등이 있는지 확인하세요.
- 버전에 따라 연결 처리가 변경될 수 있으므로 앱과 운영 체제를 최신 상태로 유지하세요.
- 영향을 이해하거나 관리자 승인을 받지 않는 한 고급 라우터 또는 방화벽 설정을 변경하지 마십시오.
이러한 단계는 제한 사항을 우회하지 않습니다. 연결 문제가 어디서 발생하는지 식별하는 데 도움이 됩니다.
NAT 순회 클레임을 주의 깊게 읽는 방법
NAT 탐색에 대해 이야기하는 제품, 프로토콜 또는 앱을 볼 때 해당 주장을 정확하게 읽으십시오.
유용한 질문은 다음과 같습니다.
- 일반적인 네트워킹 기술에 대한 주장인가요, 아니면 확인된 제품 기능에 대한 주장인가요?
- 어떤 네트워크 조건이 지원되고 어떤 것이 지원되지 않는지 설명되어 있나요?
- 완벽한 도달 가능성을 약속하지 않고 대체 동작을 언급합니까?
- 사용자가 직장, 학교, ISP, 플랫폼 또는 법적 제한을 무시할 수 있다는 것을 암시하지 않습니까?
- 개인정보 보호 주장과 연결 주장을 분리합니까?
마지막 요점은 놓치기 쉽습니다. 두 끝점을 연결하는 데 도움이 되는 기능은 자동으로 개인 정보 보호를 보장하지 않습니다. 개인 정보 보호 기능은 자동으로 연결을 보장하지 않습니다. 좋은 문서는 이러한 아이디어를 별도로 유지해야 합니다.
FAQ
NAT 순회는 VPN와 동일합니까?
아니요. NAT 탐색은 엔드포인트 간 주소 변환 및 필터링을 처리하기 위한 네트워킹 기술 세트입니다. VPN는 보호된 네트워크 터널을 생성하기 위한 보다 광범위한 기술 범주입니다. 일부 VPN 유사 앱은 NAT 동작을 설명해야 할 수도 있지만 개념은 동일하지 않습니다.
UDP 홀 펀칭은 항상 작동하나요?
아니요. UDP 홀 펀칭은 NAT 동작, 필터링 규칙, 타이밍 및 네트워크 토폴로지에 따라 달라집니다. 연구 및 표준 논의는 모두 동일한 실제 현실을 지적합니다. NAT 동작은 다양하므로 대체 경로가 필요할 수 있습니다.
직접 연결보다 릴레이 폴백이 더 좋나요?
그들은 다릅니다. 릴레이는 직접 통신이 불가능할 때 도움이 될 수 있지만 대기 시간, 대역폭 사용 및 운영 비용이 추가될 수 있습니다. 직접 경로는 작동할 때 더 효율적일 수 있지만 더 엄격한 네트워크에서는 실패할 수 있습니다.
이 기사에서는 VPN Satelites가 STUN, TURN, ICE, 릴레이 또는 포트 전달을 사용한다고 나와 있나요?
아니요. 해당 용어는 일반적인 네트워킹 개념 및 표준 배경으로 논의됩니다. 이 문서에서는 VPN Satelites에 대한 제품별 구현에 대해 주장하지 않습니다.
NAT 탐색이 네트워크 규칙을 우회할 수 있나요?
이 문서에서는 우회 지침을 제공하지 않습니다. NAT 순회는 연결 동작을 설명하는 데 도움이 될 수 있지만 사용자는 관련 법률, 서비스 약관 및 네트워크 정책을 따라야 합니다.
결론
두 장치 간의 인터넷 경로가 항상 직접적이거나 예측 가능한 것은 아니기 때문에 NAT 탐색이 중요합니다. UDP 홀 펀칭은 일부 애플리케이션이 NAT 전체에서 직접 통신을 설정하는 데 도움이 될 수 있으며, 릴레이 폴백은 직접 경로가 실패할 때 도움이 될 수 있습니다. 두 가지 아이디어 모두 유용하지만 어느 쪽도 보편적인 해결책은 아닙니다.
VPN Satelites 독자들에게 가장 실용적인 교훈은 현실적인 기대치를 설정하는 것입니다. 연결 안정성은 앱, 장치, 로컬 네트워크, 업스트림 네트워크 정책 및 엔드포인트 간의 더 넓은 경로에 따라 달라집니다. 이러한 계층을 이해하면 문제 해결이 더 차분해지고 제품 주장을 비판적으로 읽기가 더 쉬워집니다.