WireGuard를 사용하면 안 되는 이유

WireGuard는 최근 많은 주목을 받고 있으며 실제로 VPN 중에서 새로운 스타입니다. 그러나 그는 그가 보이는 것만 큼 좋은가요? IPsec 또는 OpenVPN을 대체할 솔루션이 아닌 이유를 설명하기 위해 몇 가지 관찰 사항에 대해 논의하고 WireGuard 구현을 검토하고 싶습니다.

이 기사에서는 [WireGuard에 대한] 신화의 일부를 폭로하고 싶습니다. 예, 읽는 데 시간이 오래 걸리므로 차나 커피 한 잔을 만들지 않았다면 할 시간입니다. 혼란스러운 생각을 바로잡아준 Peter에게도 감사의 말을 전하고 싶습니다.

나는 WireGuard 개발자를 불신하고 그들의 노력이나 아이디어를 평가 절하하려는 목표를 설정하지 않습니다. 그들의 제품은 작동하지만 개인적으로 실제 제품과 완전히 다르게 제공된다고 생각합니다. 실제로 현재 존재하지 않는 IPsec 및 OpenVPN을 대체하는 것으로 제공됩니다.

참고로 WireGuard의 이러한 포지셔닝에 대한 책임은 프로젝트 자체나 제작자가 아니라 그것에 대해 이야기한 미디어에 있다는 점을 덧붙이고 싶습니다.

최근에 Linux 커널에 대한 좋은 소식은 별로 없었습니다. 그래서 우리는 소프트웨어에 의해 평준화 된 프로세서의 엄청난 취약점에 대해 들었고 Linus Torvalds는 개발자의 실용적인 언어로 너무 무례하고 지루하게 그것에 대해 이야기했습니다. 스케줄러 또는 제로 레벨 네트워킹 스택도 화려한 잡지에 대한 명확한 주제가 아닙니다. 그리고 여기 WireGuard가 있습니다.

서류상으로는 모든 것이 훌륭하게 들립니다. 흥미진진한 신기술입니다.

하지만 조금 더 자세히 살펴보자.

WireGuard 백서

이 기사는 공식 WireGuard 문서제이슨 도넨펠드 작성. 여기에서 그는 Linux 커널에서 [WireGuard]의 개념, 목적 및 기술 구현에 대해 설명합니다.

첫 번째 문장은 다음과 같습니다.

WireGuard [...]는 대부분의 사용 사례에서 IPsec과 기타 널리 사용되는 사용자 공간 및/또는 OpenVPN과 같은 TLS 기반 솔루션을 보다 안전하고 성능이 뛰어나며 사용하기 쉽게 [도구]로 대체하는 것을 목표로 합니다.

물론 모든 신기술의 주요 이점은 단순함 [전작과 비교]. 그러나 VPN은 또한 효율적이고 안전한.

그리고 다음은 무엇입니까?

이것이 [VPN에서] 필요한 것이 아니라고 말하면 여기에서 읽기를 종료할 수 있습니다. 그러나 이러한 작업은 다른 터널링 기술에 대해 설정되어 있습니다.

위의 인용문 중 가장 흥미로운 것은 "대부분의 경우"라는 단어에 있습니다. 물론 언론에서는 무시했습니다. 그래서 우리는 이 기사에서 이러한 태만으로 인해 발생한 혼돈으로 인해 결국 우리가 있는 곳입니다.

WireGuard가 내 [IPsec] 사이트 간 VPN을 대체합니까?

아니요. Cisco, Juniper 등과 같은 대형 공급업체가 자사 제품을 위해 WireGuard를 구매할 가능성은 전혀 없습니다. 그들은 그렇게 해야 할 큰 필요가 있지 않는 한 이동 중에 "지나가는 기차에 뛰어오르지" 않습니다. 나중에 그들이 원하더라도 WireGuard 제품을 탑재할 수 없는 몇 가지 이유를 살펴보겠습니다.

WireGuard는 RoadWarrior를 노트북에서 데이터 센터로 가져가나요?

아니요. 현재 WireGuard에는 이와 같은 작업을 수행할 수 있도록 구현된 중요한 기능이 많지 않습니다. 예를 들어 터널 서버 측에서 동적 IP 주소를 사용할 수 없으며 이것만으로도 제품 사용의 전체 시나리오가 중단됩니다.

IPFire는 종종 DSL 또는 케이블 연결과 같은 저렴한 인터넷 링크에 사용됩니다. 이는 빠른 광섬유가 필요하지 않은 중소기업에 적합합니다. [번역가의 참고 사항 : 통신 측면에서 러시아와 일부 CIS 국가는 유럽과 미국보다 훨씬 앞서 있다는 사실을 잊지 마십시오. 우리는 훨씬 늦게 네트워크를 구축하기 시작했고 이더넷 및 광섬유 네트워크가 표준, 우리가 재건하는 것이 더 쉬웠습니다. EU 또는 미국의 동일한 국가에서는 3-5Mbps 속도의 xDSL 광대역 액세스가 여전히 일반적인 표준이며 광섬유 연결에는 우리 표준에 따라 비현실적인 비용이 듭니다. 따라서 글의 저자는 고대가 아닌 DSL이나 케이블 연결을 표준으로 이야기합니다.] 그러나 DSL, 케이블, LTE(및 기타 무선 액세스 방법)에는 동적 IP 주소가 있습니다. 물론 자주 바뀌지 않을 때도 있지만 바뀌기는 합니다.

라는 하위 프로젝트가 있습니다. "wg-동적", 이 단점을 극복하기 위해 사용자 공간 데몬을 추가합니다. 위에서 설명한 사용자 시나리오의 큰 문제는 동적 IPv6 주소 지정의 악화입니다.

배급사의 관점에서 볼 때 이 모든 것이 그리 좋아 보이지는 않습니다. 설계 목표 중 하나는 프로토콜을 단순하고 깔끔하게 유지하는 것이었습니다.

불행하게도 이 모든 것이 실제로는 너무 단순하고 원시적이어서 이 전체 디자인이 실제로 사용 가능하려면 추가 소프트웨어를 사용해야 합니다.

WireGuard는 사용하기 쉬운가요?

아직 아님. WireGuard가 두 지점 사이의 터널링을 위한 좋은 대안이 될 수 없다는 말은 아니지만 현재로서는 예상되는 제품의 알파 버전일 뿐입니다.

그러나 그는 실제로 무엇을합니까? IPsec은 정말 유지하기가 훨씬 더 어렵습니까?

당연히 아니. IPsec 공급업체는 이를 고려하여 IPFire와 같은 인터페이스와 함께 제품을 제공합니다.

IPsec을 통해 VPN 터널을 설정하려면 구성에 입력해야 하는 XNUMX가지 데이터 세트가 필요합니다. 자신의 공용 IP 주소, 수신자의 공용 IP 주소, 공개하려는 서브넷 이 VPN 연결 및 사전 공유 키. 따라서 VPN은 몇 분 안에 설정되며 모든 공급업체와 호환됩니다.

불행히도 이 이야기에는 몇 가지 예외가 있습니다. IPsec을 통해 OpenBSD 시스템으로 터널링을 시도한 사람이라면 누구나 내가 말하는 내용을 알 것입니다. 고통스러운 예가 몇 가지 더 있지만 실제로는 IPsec을 사용하기 위한 더 많은 좋은 사례가 있습니다.

프로토콜 복잡성 정보

최종 사용자는 프로토콜의 복잡성에 대해 걱정할 필요가 없습니다.

이것이 사용자의 진정한 관심사인 세상에 살고 있다면 NAT와 잘 작동하지 않는 SIP, H.323, FTP 및 XNUMX년 이상 전에 만들어진 기타 프로토콜을 제거했을 것입니다.

IPsec이 WireGuard보다 더 복잡한 이유가 있습니다. 더 많은 일을 합니다. 예를 들어 로그인/비밀번호 또는 EAP가 있는 SIM 카드를 사용한 사용자 인증입니다. 새로운 기능을 추가할 수 있는 확장된 기능이 있습니다. 암호화 프리미티브.

WireGuard에는 그런 기능이 없습니다.

그리고 이것은 WireGuard가 어느 시점에서 중단된다는 것을 의미합니다. 암호화 기본 요소 중 하나가 약해지거나 완전히 손상되기 때문입니다. 기술 문서의 저자는 이렇게 말합니다.

WireGuard가 암호학적으로 독단적이라는 점은 주목할 가치가 있습니다. 의도적으로 암호 및 프로토콜의 유연성이 부족합니다. 기본 프리미티브에서 심각한 구멍이 발견되면 모든 엔드포인트를 업데이트해야 합니다. 계속되는 SLL/TLS 취약성 스트림에서 알 수 있듯이 암호화의 유연성이 이제 엄청나게 증가했습니다.

마지막 문장이 절대적으로 맞습니다.

사용할 암호화에 대한 합의에 도달하면 IKE 및 TLS와 같은 프로토콜이 만들어집니다. 더 복잡한. 너무 복잡한? 예, 취약성은 TLS/SSL에서 매우 일반적이며 이에 대한 대안이 없습니다.

실제 문제를 무시할 때

전 세계 어딘가에 200개의 전투 클라이언트가 있는 VPN 서버가 있다고 상상해 보십시오. 이것은 꽤 표준적인 사용 사례입니다. 암호화를 변경해야 하는 경우 이러한 랩톱, 스마트폰 등에 있는 모든 WireGuard 복사본에 업데이트를 제공해야 합니다. 동시에 배달하다. 말 그대로 불가능합니다. 이 작업을 수행하려는 관리자는 필요한 구성을 배포하는 데 몇 달이 걸리며 이러한 이벤트를 실행하는 데 말 그대로 중간 규모 회사는 몇 년이 걸립니다.

IPsec 및 OpenVPN은 암호 협상 기능을 제공합니다. 따라서 새 암호화를 켠 후 얼마 동안은 이전 암호화도 작동합니다. 이렇게 하면 현재 고객이 새 버전으로 업그레이드할 수 있습니다. 업데이트가 출시된 후 취약한 암호화를 해제하기만 하면 됩니다. 그리고 그게 다야! 준비가 된! 너는 아주 멋져! 고객은 그것을 알아채지도 못할 것입니다.

이것은 실제로 대규모 배포의 경우 매우 일반적인 경우이며 OpenVPN조차도 이에 약간의 어려움이 있습니다. 이전 버전과의 호환성은 중요하며 더 약한 암호화를 사용하더라도 많은 경우 이것이 비즈니스를 닫을 이유가 되지 않습니다. 업무를 수행할 수 없기 때문에 수백 명의 고객의 업무를 마비시킬 것이기 때문입니다.

WireGuard 팀은 프로토콜을 더 간단하게 만들었지만 터널의 두 피어를 지속적으로 제어할 수 없는 사람들에게는 완전히 사용할 수 없습니다. 내 경험상 이것은 가장 일반적인 시나리오입니다.

암호화!

그러나 WireGuard가 사용하는 흥미로운 새 암호화는 무엇입니까?

WireGuard는 키 교환에 Curve25519, 암호화에 ChaCha20, 데이터 인증에 Poly1305를 사용합니다. 또한 해시 키용 SipHash 및 해싱용 BLAKE2와 함께 작동합니다.

ChaCha20-Poly1305는 IPsec 및 OpenVPN(TLS 사용)에 대해 표준화되었습니다.

Daniel Bernstein의 개발이 매우 자주 사용되는 것은 당연합니다. BLAKE2는 SHA-3와의 유사성 때문에 우승하지 못한 SHA-2 결선 진출자인 BLAKE의 후속작입니다. SHA-2가 손상되면 BLAKE도 손상될 가능성이 높습니다.

IPsec 및 OpenVPN은 설계상 SipHash가 필요하지 않습니다. 그래서 현재 그들과 함께 사용할 수 없는 유일한 것은 BLAKE2이며, 그것은 표준화될 때까지만 가능합니다. VPN은 HMAC를 사용하여 무결성을 생성하기 때문에 이는 큰 단점이 아니며 MD5와 함께 사용하더라도 강력한 솔루션으로 간주됩니다.

그래서 거의 동일한 암호화 도구 세트가 모든 VPN에서 사용된다는 결론에 도달했습니다. 따라서 WireGuard는 전송된 데이터의 암호화 또는 무결성과 관련하여 다른 현재 제품보다 더 안전하거나 덜 안전하지 않습니다.

그러나 이것조차도 가장 중요한 것은 아니며 프로젝트의 공식 문서에 따르면 주목할 가치가 있습니다. 결국 가장 중요한 것은 속도입니다.

WireGuard는 다른 VPN 솔루션보다 빠릅니까?

요컨대, 아니오, 더 빠르지는 않습니다.

ChaCha20은 소프트웨어로 구현하기 쉬운 스트림 암호입니다. 한 번에 한 비트씩 암호화합니다. AES와 같은 블록 프로토콜은 한 번에 128비트씩 블록을 암호화합니다. 하드웨어 지원을 구현하려면 훨씬 더 많은 트랜지스터가 필요하므로 더 큰 프로세서에는 속도를 높이기 위해 암호화 프로세스의 일부 작업을 수행하는 명령 집합 확장인 AES-NI가 함께 제공됩니다.

AES-NI는 스마트폰에 절대 들어가지 않을 것으로 예상되었지만 [하지만 그랬습니다. 당.]. 이를 위해 ChaCha20은 가볍고 배터리를 절약하는 대안으로 개발되었습니다. 따라서 오늘날 구입할 수 있는 모든 스마트폰에는 일종의 AES 가속 기능이 있으며 ChaCha20보다 이 암호화를 통해 더 빠르고 전력 소비가 적다는 소식이 들릴 수 있습니다.

분명히 지난 몇 년 동안 구입한 거의 모든 데스크톱/서버 프로세서에는 AES-NI가 있습니다.

따라서 모든 단일 시나리오에서 AES가 ChaCha20을 능가할 것으로 기대합니다. WireGuard의 공식 문서에 따르면 AVX512를 사용하면 ChaCha20-Poly1305가 AES-NI보다 성능이 우수하지만 이 명령어 세트 확장은 더 큰 CPU에서만 사용할 수 있으며 더 작고 더 많은 모바일 하드웨어에는 도움이 되지 않으며 AES에서는 항상 더 빠릅니다. -N.I.

WireGuard를 개발하는 동안 이것이 예견될 수 있었는지 확실하지 않지만 오늘날 암호화에만 못 박혀 있다는 사실은 이미 작동에 그다지 영향을 미치지 않을 수도 있는 단점입니다.

IPsec을 사용하면 상황에 가장 적합한 암호화를 자유롭게 선택할 수 있습니다. 물론 이것은 예를 들어 VPN 연결을 통해 10GB 이상의 데이터를 전송하려는 경우에 필요합니다.

Linux의 통합 문제

WireGuard는 최신 암호화 프로토콜을 선택했지만 이미 많은 문제가 발생했습니다. 따라서 기본적으로 커널에서 지원하는 것을 사용하는 대신 WireGuard의 통합은 Linux에 이러한 기본 요소가 없기 때문에 몇 년 동안 지연되었습니다.

다른 운영 체제의 상황이 어떤지 완전히 확신할 수는 없지만 아마도 Linux와 크게 다르지 않을 것입니다.

현실은 어떤 모습일까요?

안타깝게도 고객이 VPN 연결 설정을 요청할 때마다 오래된 자격 증명과 암호화를 사용하고 있다는 문제에 직면하게 됩니다. MD3와 함께 5DES는 AES-256 및 SHA1과 마찬가지로 여전히 일반적인 관행입니다. 후자가 약간 더 낫긴 하지만 2020년에 사용해야 하는 것은 아닙니다.

키 교환용 항상 느리지만 상당히 안전한 도구인 RSA가 사용됩니다.

내 고객은 세관 당국 및 기타 정부 조직 및 기관뿐만 아니라 전 세계에 이름이 알려진 대기업과 관련되어 있습니다. 그들은 모두 수십 년 전에 생성된 요청 양식을 사용하며 SHA-512를 사용하는 기능은 추가되지 않았습니다. 어떻게든 기술 발전에 분명히 영향을 미친다고 말할 수는 없지만 분명히 기업 프로세스가 느려집니다.

IPsec이 2005년부터 직접 타원 곡선을 지원해 왔기 때문에 이것을 보는 것이 마음이 아픕니다. Curve25519도 최신 버전이며 사용할 수 있습니다. Camellia 및 ChaCha20과 같은 AES에 대한 대안도 있지만 Cisco 및 기타와 같은 주요 공급업체에서 이들 모두를 지원하는 것은 아닙니다.

그리고 사람들은 그것을 이용합니다. 많은 Cisco 키트가 있으며 Cisco와 함께 작동하도록 설계된 많은 키트가 있습니다. 그들은 이 부문의 시장 리더이며 어떤 종류의 혁신에도 그다지 관심이 없습니다.

예, [기업 부문의] 상황은 끔찍하지만 WireGuard로 인해 변경 사항이 표시되지 않습니다. 공급업체는 이미 사용하고 있는 도구 및 암호화의 성능 문제를 전혀 보지 못할 것이며 IKEv2의 어떤 문제도 보지 않을 것이므로 대안을 찾지 않을 것입니다.

일반적으로 Cisco를 포기하는 것에 대해 생각해 본 적이 있습니까?

벤치마크

이제 WireGuard 설명서의 벤치마크로 이동하겠습니다. 이 [문서]는 과학적인 기사는 아니지만 개발자가 더 과학적인 접근 방식을 취하거나 과학적인 접근 방식을 참조로 사용하기를 여전히 기대했습니다. 재현할 수 없는 벤치마크는 쓸모가 없으며 실험실에서 얻은 벤치마크는 더욱 쓸모가 없습니다.

WireGuard의 Linux 빌드에서는 GSO(Generic Segmentation Offloading)를 사용합니다. 그 덕분에 클라이언트는 64KB의 거대한 패킷을 생성하고 한 번에 암호화/암호 해독합니다. 따라서 암호화 작업을 호출하고 구현하는 비용이 절감됩니다. VPN 연결의 처리량을 최대화하려면 이것이 좋은 생각입니다.

그러나 늘 그렇듯이 현실은 그렇게 단순하지 않습니다. 이러한 큰 패킷을 네트워크 어댑터로 보내려면 많은 작은 패킷으로 잘라야 합니다. 일반적인 전송 크기는 1500바이트입니다. 즉, 우리의 거대한 64킬로바이트는 45개의 패킷(1240바이트의 정보와 20바이트의 IP 헤더)으로 나뉩니다. 그런 다음 한 번에 함께 보내야하기 때문에 잠시 동안 네트워크 어댑터의 작업을 완전히 차단합니다. 결과적으로 이것은 우선 순위 점프로 이어지고 예를 들어 VoIP와 같은 패킷이 대기하게 됩니다.

따라서 WireGuard가 대담하게 주장하는 높은 처리량은 다른 애플리케이션의 네트워킹 속도를 낮추는 대가로 달성됩니다. 그리고 WireGuard 팀은 이미 확인 된 이것이 나의 결론이다.

그러나 계속 진행합시다.

기술 문서의 벤치마크에 따르면 연결은 1011Mbps의 처리량을 보여줍니다.

인상적.

이는 단일 기가비트 이더넷 연결의 이론적 최대 처리량이 966Mbps이고 패킷 크기가 1500바이트에서 IP 헤더의 경우 20바이트, UDP 헤더의 경우 8바이트, WireGuard 자체. 캡슐화된 패킷에는 IP 헤더가 하나 더 있고 TCP에는 16바이트용 IP 헤더가 하나 더 있습니다. 그렇다면 이 추가 대역폭은 어디에서 왔습니까?

거대한 프레임과 위에서 언급한 GSO의 이점으로 인해 9000바이트의 프레임 크기에 대한 이론적 최대값은 1014Mbps가 됩니다. 일반적으로 이러한 처리량은 큰 어려움과 관련되어 있기 때문에 실제로는 달성할 수 없습니다. 따라서 일부 네트워크 어댑터에서만 지원되는 이론상 최대 64Mbps인 1023KB의 훨씬 더 큰 대형 프레임을 사용하여 테스트를 수행했다고 가정할 수 있습니다. 그러나 이것은 실제 조건에서는 절대적으로 적용할 수 없거나 테스트 벤치 내에서 독점적으로 직접 연결된 두 스테이션 사이에서만 사용할 수 있습니다.

그러나 VPN 터널은 점보 프레임을 전혀 지원하지 않는 인터넷 연결을 사용하여 두 호스트 간에 전달되기 때문에 벤치에서 얻은 결과를 벤치마크로 사용할 수 없습니다. 이것은 단순히 실제 전투 조건에서 불가능하고 적용할 수 없는 비현실적인 실험실 성과입니다.

데이터 센터에 앉아 있어도 9000바이트가 넘는 프레임을 전송할 수 없었습니다.

실생활에서의 적용 가능성의 기준은 절대적으로 위반되며 "측정"의 저자는 명백한 이유로 자신을 심각하게 불신했습니다.

마지막 희망의 빛

WireGuard 웹사이트는 컨테이너에 대해 많이 이야기하고 그것이 실제로 무엇을 위한 것인지 분명해집니다.

구성이 필요 없고 Amazon과 같은 대규모 오케스트레이션 도구를 사용하여 클라우드에 배포 및 구성할 수 있는 간단하고 빠른 VPN입니다. 특히 Amazon은 앞서 언급한 AVX512와 같은 최신 하드웨어 기능을 사용합니다. 이것은 작업 속도를 높이고 x86 또는 다른 아키텍처에 얽매이지 않기 위해 수행됩니다.

9000바이트보다 큰 처리량과 패킷을 최적화합니다. 이는 컨테이너가 서로 통신하거나 백업 작업, 스냅샷 생성 또는 동일한 컨테이너 배포를 위해 캡슐화된 거대한 프레임이 됩니다. 내가 설명한 시나리오의 경우 동적 IP 주소도 WireGuard의 작동에 어떤 식으로든 영향을 미치지 않습니다.

잘 놀았다. 훌륭한 구현과 매우 얇고 거의 참조 프로토콜입니다.

그러나 그것은 당신이 완전히 통제하는 데이터 센터 외부의 세계에는 적합하지 않습니다. 위험을 감수하고 WireGuard를 사용하기 시작하면 암호화 프로토콜의 설계 및 구현에서 지속적으로 절충해야 합니다.

출력

WireGuard가 아직 준비되지 않았다는 결론을 쉽게 내릴 수 있습니다.

기존 솔루션의 여러 문제에 대한 가볍고 빠른 솔루션으로 생각되었습니다. 불행히도 이러한 솔루션을 위해 그는 대부분의 사용자와 관련된 많은 기능을 희생했습니다. 이것이 IPsec 또는 OpenVPN을 대체할 수 없는 이유입니다.

WireGuard가 경쟁력을 갖추려면 최소한 IP 주소 설정과 라우팅 및 DNS 구성을 추가해야 합니다. 분명히 이것이 암호화된 채널의 목적입니다.

보안은 저의 최우선 순위이며 지금 당장은 IKE 또는 TLS가 어떤 식으로든 손상되거나 손상되었다고 믿을 이유가 없습니다. 최신 암호화는 두 가지 모두에서 지원되며 수십 년 동안 작동하여 입증되었습니다. 어떤 것이 더 새롭다고 해서 더 좋은 것은 아닙니다.

상호 운용성은 귀하가 제어하지 않는 스테이션을 가진 제XNUMX자와 통신할 때 매우 중요합니다. IPsec은 사실상의 표준이며 거의 모든 곳에서 지원됩니다. 그리고 그는 일합니다. 그리고 그것이 어떻게 보이든 이론적으로 WireGuard는 미래에 다른 버전과도 호환되지 않을 수 있습니다.

모든 암호화 보호는 조만간 손상되므로 교체하거나 업데이트해야 합니다.

이러한 모든 사실을 부인하고 맹목적으로 WireGuard를 사용하여 iPhone을 홈 워크스테이션에 연결하려는 것은 머리를 모래에 꽂는 마스터 클래스에 불과합니다.

출처 : habr.com