WireGuard está a gañar moita atención ultimamente, de feito é a nova estrela entre as VPN. Pero é tan bo como parece? Gustaríame comentar algunhas observacións e revisar a implementación de WireGuard para explicar por que non é unha solución para substituír IPsec ou OpenVPN.
Neste artigo, gustaríame desacreditar algúns dos mitos [en torno a WireGuard]. Si, tardarás moito en ler, así que se non fixeches unha cunca de té ou café, é hora de facelo. Tamén me gustaría agradecer a Peter por corrixir os meus caóticos pensamentos.
Non me propoño o obxectivo de desacreditar aos desenvolvedores de WireGuard, desvalorizando os seus esforzos ou ideas. O seu produto está funcionando, pero persoalmente creo que se presenta completamente diferente do que é realmente: preséntase como un substituto de IPsec e OpenVPN, que de feito simplemente non existe agora.
Como nota, gustaríame engadir que a responsabilidade de tal posicionamento de WireGuard é dos medios que falaron del, e non do propio proxecto nin dos seus creadores.
Non houbo moitas boas noticias sobre o núcleo Linux ultimamente. Entón, faláronnos das monstruosas vulnerabilidades do procesador, que foron niveladas polo software, e Linus Torvalds falou sobre iso de forma demasiado ruda e aburrida, na linguaxe utilitaria do programador. Un programador ou unha pila de rede de nivel cero tampouco son temas moi claros para as revistas brillantes. E aquí vén WireGuard.
No papel, todo soa xenial: unha nova tecnoloxía emocionante.
Pero vexámolo un pouco máis de preto.
Libro branco WireGuard
Este artigo baséase en escrito por Jason Donenfeld. Alí explica o concepto, propósito e implementación técnica de [WireGuard] no núcleo de Linux.
A primeira frase di:
WireGuard […] pretende substituír tanto IPsec na maioría dos casos de uso como outras solucións populares baseadas en espazos de usuario e/ou TLS como OpenVPN á vez que é máis segura, eficiente e máis fácil de usar [ferramenta].
Por suposto, a principal vantaxe de todas as novas tecnoloxías é a súa sinxeleza [comparado cos predecesores]. Pero unha VPN tamén debería ser eficaz e segura.
Entón, que é o seguinte?
Se dis que isto non é o que necesitas [dunha VPN], podes rematar a lectura aquí. Non obstante, notarei que tales tarefas están establecidas para calquera outra tecnoloxía de túnel.
O máis interesante da cita anterior reside nas palabras "na maioría dos casos", que, por suposto, foron ignoradas pola prensa. E así, estamos onde acabamos debido ao caos creado por esta neglixencia, neste artigo.
WireGuard substituirá a miña VPN de sitio a sitio [IPsec]?
Non. Simplemente non hai posibilidades de que grandes provedores como Cisco, Juniper e outros compren WireGuard para os seus produtos. Non "saltan sobre trens que pasan" en movemento a non ser que haxa moita necesidade de facelo. Máis tarde, repasarei algunhas das razóns polas que probablemente non poderán incorporar os seus produtos WireGuard aínda que quixesen.
WireGuard levará o meu RoadWarrior do meu portátil ao centro de datos?
Non. Agora mesmo, WireGuard non ten un gran número de funcións importantes implementadas para que poida facer algo así. Por exemplo, non pode usar enderezos IP dinámicos no lado do servidor do túnel, e só isto rompe todo o escenario de tal uso do produto.
IPFire úsase a miúdo para conexións de Internet baratas, como conexións DSL ou por cable. Isto ten sentido para as pequenas ou medianas empresas que non necesitan fibra rápida. [Nota do tradutor: non esquezas que en materia de comunicación, Rusia e algúns países da CEI están moi por diante de Europa e Estados Unidos, porque comezamos a construír as nosas redes moito máis tarde e coa chegada de Ethernet e redes de fibra óptica como estándar, foinos máis fácil reconstruír. Nos mesmos países da UE ou dos EUA, o acceso a banda ancha xDSL a unha velocidade de 3-5 Mbps segue sendo a norma xeral, e unha conexión de fibra óptica custa un diñeiro pouco realista segundo os nosos estándares. Polo tanto, o autor do artigo fala de DSL ou conexión por cable como norma, e non tempos antigos.] Non obstante, DSL, cable, LTE (e outros métodos de acceso sen fíos) teñen enderezos IP dinámicos. Por suposto, ás veces non cambian a miúdo, pero si cambian.
Hai un subproxecto chamado , que engade un daemon de espazo de usuario para superar esta deficiencia. Un gran problema co escenario de usuario descrito anteriormente é o agravamento do enderezo IPv6 dinámico.
Desde o punto de vista da distribuidora, todo isto tampouco se ve moi ben. Un dos obxectivos do deseño era manter o protocolo sinxelo e limpo.
Desafortunadamente, todo isto volveuse demasiado sinxelo e primitivo, polo que temos que usar software adicional para que todo este deseño sexa viable nun uso real.
É tan fácil de usar WireGuard?
Aínda non. Non digo que WireGuard nunca será unha boa alternativa para facer túneles entre dous puntos, pero polo momento é só unha versión alfa do produto que se supón que debe ser.
Pero entón que fai realmente? IPsec é realmente moito máis difícil de manter?
Obviamente non. O vendedor de IPsec pensou nisto e envía o seu produto xunto cunha interface, como IPFire.
Para configurar un túnel VPN a través de IPsec, necesitará cinco conxuntos de datos que necesitará introducir na configuración: o seu propio enderezo IP público, o enderezo IP público da parte receptora, as subredes que quere facer públicas a través de IPsec. esta conexión VPN e clave precompartida. Así, a VPN está configurada en poucos minutos e é compatible con calquera provedor.
Desafortunadamente, hai algunhas excepcións a esta historia. Calquera que intentou facer un túnel a través de IPsec a unha máquina OpenBSD sabe do que estou a falar. Hai un par de exemplos máis dolorosos, pero, de feito, hai moitas, moitas máis boas prácticas para usar IPsec.
Sobre a complexidade do protocolo
O usuario final non ten que preocuparse pola complexidade do protocolo.
Se vivisemos nun mundo no que esta era unha preocupación real do usuario, entón desfaceriamos SIP, H.323, FTP e outros protocolos creados hai máis de dez anos que non funcionan ben con NAT.
Hai razóns polas que IPsec é máis complexo que WireGuard: fai moitas máis cousas. Por exemplo, a autenticación do usuario mediante un inicio de sesión/contrasinal ou unha tarxeta SIM con EAP. Ten unha capacidade ampliada para engadir novas .
E WireGuard non ten iso.
E isto significa que WireGuard romperase nalgún momento, porque un dos primitivos criptográficos debilitarase ou estará completamente comprometido. O autor da documentación técnica di isto:
Paga a pena notar que WireGuard é criptograficamente opinado. Carece deliberadamente da flexibilidade dos cifrados e dos protocolos. Se se atopan buratos graves nas primitivas subxacentes, haberá que actualizar todos os puntos finais. Como podes ver no fluxo de vulnerabilidades SLL/TLS en curso, a flexibilidade do cifrado aumentou enormemente.
A última frase é absolutamente correcta.
Chegar a un consenso sobre que cifrado usar fai protocolos como IKE e TLS Máis complexo. Demasiado complicado? Si, as vulnerabilidades son bastante comúns en TLS/SSL e non hai alternativa a elas.
En ignorar os problemas reais
Imaxina que tes un servidor VPN con 200 clientes de combate en todo o mundo. Este é un caso de uso bastante estándar. Se tes que cambiar o cifrado, debes entregar a actualización a todas as copias de WireGuard nestes portátiles, teléfonos intelixentes, etc. Simultaneamente entregar. É literalmente imposible. Os administradores que intenten facelo tardarán meses en implementar as configuracións necesarias e, literalmente, unha empresa mediana levará anos para levar a cabo un evento deste tipo.
IPsec e OpenVPN ofrecen unha función de negociación de cifrado. Polo tanto, durante algún tempo despois de activar o novo cifrado, o antigo tamén funcionará. Isto permitirá aos clientes actuais actualizar á nova versión. Despois de lanzar a actualización, simplemente desactiva o cifrado vulnerable. E iso é todo! Listo! estás preciosa! Os clientes nin sequera o notarán.
Este é en realidade un caso moi común para grandes despregamentos, e incluso OpenVPN ten algunha dificultade con isto. A compatibilidade con versións anteriores é importante, e aínda que usas un cifrado máis débil, para moitos, este non é un motivo para pechar unha empresa. Porque paralizará o traballo de centos de clientes pola imposibilidade de facer o seu traballo.
O equipo de WireGuard fixo que o seu protocolo sexa máis sinxelo, pero completamente inutilizable para as persoas que non teñen un control constante sobre os dous pares no seu túnel. Na miña experiencia, este é o escenario máis común.
Criptografía!
Pero que é este novo cifrado interesante que usa WireGuard?
WireGuard usa Curve25519 para o intercambio de claves, ChaCha20 para o cifrado e Poly1305 para a autenticación de datos. Tamén funciona con SipHash para chaves hash e BLAKE2 para hash.
ChaCha20-Poly1305 está estandarizado para IPsec e OpenVPN (sobre TLS).
É obvio que o desenvolvemento de Daniel Bernstein utilízase con moita frecuencia. BLAKE2 é o sucesor de BLAKE, un finalista de SHA-3 que non gañou debido á súa semellanza con SHA-2. Se o SHA-2 se rompese, había unha boa posibilidade de que BLAKE tamén se vese comprometido.
IPsec e OpenVPN non necesitan SipHash debido ao seu deseño. Polo tanto, o único que actualmente non se pode usar con eles é BLAKE2, e iso só ata que estea estandarizado. Este non é un gran inconveniente, porque as VPN usan HMAC para crear integridade, que se considera unha solución forte mesmo en conxunto con MD5.
Entón cheguei á conclusión de que se usa case o mesmo conxunto de ferramentas criptográficas en todas as VPN. Polo tanto, WireGuard non é máis nin menos seguro que calquera outro produto actual no que se refire ao cifrado ou á integridade dos datos transmitidos.
Pero nin sequera isto é o máis importante, ao que paga a pena prestar atención segundo a documentación oficial do proxecto. Despois de todo, o principal é a velocidade.
WireGuard é máis rápido que outras solucións VPN?
En resumo: non, non máis rápido.
ChaCha20 é un cifrado de fluxo que é máis fácil de implementar no software. Cifra un bit á vez. Os protocolos de bloque como AES cifran un bloque de 128 bits á vez. Requírense moitos máis transistores para implementar soporte de hardware, polo que os procesadores máis grandes veñen con AES-NI, unha extensión de conxunto de instrucións que realiza algunhas das tarefas do proceso de cifrado para aceleralo.
Esperábase que AES-NI nunca entrase nos teléfonos intelixentes [pero fíxoo - aprox. por.]. Para iso, o ChaCha20 foi desenvolvido como unha alternativa lixeira e de aforro de batería. Polo tanto, pode ser unha noticia para ti que todos os teléfonos intelixentes que podes mercar hoxe teñen algún tipo de aceleración AES e funcionan máis rápido e con menor consumo de enerxía con este cifrado que con ChaCha20.
Obviamente, case todos os procesadores de escritorio/servidor comprados nos últimos anos teñen AES-NI.
Polo tanto, espero que AES supere a ChaCha20 en cada escenario. A documentación oficial de WireGuard menciona que con AVX512, ChaCha20-Poly1305 superará a AES-NI, pero esta extensión do conxunto de instrucións só estará dispoñible en CPU máis grandes, o que de novo non axudará con hardware máis pequeno e móbil, que sempre será máis rápido con AES. - N.I.
Non sei se isto podería terse previsto durante o desenvolvemento de WireGuard, pero hoxe en día o feito de que estea clavado só no cifrado xa é un inconveniente que quizais non afecte moi ben o seu funcionamento.
IPsec permítelle escoller libremente que cifrado é mellor para o seu caso. E, por suposto, isto é necesario se, por exemplo, queres transferir 10 ou máis gigabytes de datos a través dunha conexión VPN.
Problemas de integración en Linux
Aínda que WireGuard escolleu un protocolo de cifrado moderno, isto xa causa moitos problemas. E así, en lugar de usar o que admite o núcleo fóra da caixa, a integración de WireGuard atrasouse durante anos debido á falta destes primitivos en Linux.
Non estou totalmente seguro de cal é a situación noutros sistemas operativos, pero probablemente non sexa moi diferente á de Linux.
Como é a realidade?
Desafortunadamente, cada vez que un cliente me pide que configure unha conexión VPN para eles, atópome co problema de que están a usar credenciais e cifrado desactualizados. O 3DES en conxunto con MD5 aínda é unha práctica común, como o son AES-256 e SHA1. E aínda que este último é lixeiramente mellor, isto non é algo que debería usarse en 2020.
Para intercambio de chaves sempre Utilízase RSA, unha ferramenta lenta pero bastante segura.
Os meus clientes están asociados con autoridades aduaneiras e outras organizacións e institucións gobernamentais, así como con grandes corporacións cuxos nomes son coñecidos en todo o mundo. Todos usan un formulario de solicitude que se creou hai décadas e a posibilidade de usar SHA-512 simplemente nunca se engadiu. Non podo dicir que afecte claramente ao progreso tecnolóxico, pero obviamente ralentiza o proceso corporativo.
Dóame ver isto, porque IPsec admitiu curvas elípticas desde o ano 2005. Curve25519 tamén é máis recente e dispoñible para o seu uso. Tamén hai alternativas a AES como Camellia e ChaCha20, pero obviamente non todas son compatibles con grandes provedores como Cisco e outros.
E a xente aprovéitao. Hai moitos kits de Cisco, hai moitos kits deseñados para funcionar con Cisco. Son líderes do mercado neste segmento e non están moi interesados en ningún tipo de innovación.
Si, a situación [no segmento corporativo] é terrible, pero non veremos ningún cambio por mor de WireGuard. Probablemente, os provedores nunca verán ningún problema de rendemento coas ferramentas e o cifrado que xa están usando, non verán ningún problema con IKEv2 e, polo tanto, non buscan alternativas.
En xeral, xa pensaches en abandonar Cisco?
Puntos de referencia
E agora pasemos aos puntos de referencia da documentación de WireGuard. Aínda que esta [documentación] non é un artigo científico, aínda esperaba que os desenvolvedores adoptasen un enfoque máis científico ou utilizasen un enfoque científico como referencia. Calquera punto de referencia é inútil se non se pode reproducir, e máis inútil aínda cando se obteñen no laboratorio.
Na versión Linux de WireGuard, aproveita o uso de GSO - Generic Segmentation Offloading. Grazas a el, o cliente crea un enorme paquete de 64 kilobytes e cífrao / descifrado dunha soa vez. Así, redúcese o custo de invocar e implementar operacións criptográficas. Se queres maximizar o rendemento da túa conexión VPN, esta é unha boa idea.
Pero, como é habitual, a realidade non é tan sinxela. Enviar un paquete tan grande a un adaptador de rede require que se corte en moitos paquetes máis pequenos. O tamaño de envío normal é de 1500 bytes. É dicir, o noso xigante de 64 kilobytes estará dividido en 45 paquetes (1240 bytes de información e 20 bytes da cabeceira IP). Despois, durante un tempo, bloquearán completamente o traballo do adaptador de rede, porque deben enviarse xuntos e dunha vez. Como resultado, isto levará a un salto prioritario e paquetes como VoIP, por exemplo, quedarán en cola.
Así, o alto rendemento que WireGuard afirma tan audazmente conséguese a costa de ralentizar a conexión en rede doutras aplicacións. E o equipo de WireGuard xa está esta é a miña conclusión.
Pero sigamos adiante.
Segundo os puntos de referencia da documentación técnica, a conexión mostra un rendemento de 1011 Mbps.
Impresionante.
Isto é especialmente impresionante debido ao feito de que o rendemento máximo teórico dunha única conexión Gigabit Ethernet é de 966 Mbps cun tamaño de paquete de 1500 bytes menos 20 bytes para a cabeceira IP, 8 bytes para a cabeceira UDP e 16 bytes para a cabeceira de o propio WireGuard. Hai unha cabeceira IP máis no paquete encapsulado e outra en TCP para 20 bytes. Entón, de onde veu este ancho de banda extra?
Con fotogramas enormes e os beneficios de GSO dos que falamos anteriormente, o máximo teórico para un tamaño de fotograma de 9000 bytes sería de 1014 Mbps. Normalmente, tal rendemento é inalcanzable na realidade, porque está asociado a grandes dificultades. Así, só podo supoñer que a proba se realizou usando cadros de gran tamaño aínda máis gordos de 64 kilobytes cun máximo teórico de 1023 Mbps, que só admiten algúns adaptadores de rede. Pero isto é absolutamente inaplicable en condicións reais, ou só se pode utilizar entre dúas estacións conectadas directamente, exclusivamente dentro do banco de probas.
Pero dado que o túnel VPN envíase entre dous anfitrións mediante unha conexión a Internet que non admite en absoluto marcos jumbo, o resultado acadado no banco non se pode tomar como referencia. Este é simplemente un logro de laboratorio pouco realista que é imposible e inaplicable en condicións de combate reais.
Aínda sentado no centro de datos, non puiden transferir fotogramas de máis de 9000 bytes.
O criterio de aplicabilidade na vida real está absolutamente vulnerado e, como penso, o autor da "medición" realizada desacreditouse seriamente por razóns obvias.
Último brillo de esperanza
O sitio web de WireGuard fala moito de contedores e queda claro para que está realmente destinado.
Unha VPN sinxela e rápida que non require configuración e que se pode despregar e configurar con ferramentas de orquestración masivas como as que ten Amazon na súa nube. En concreto, Amazon usa as últimas funcións de hardware que mencionei anteriormente, como o AVX512. Isto faise co fin de acelerar o traballo e non estar ligado a x86 ou a calquera outra arquitectura.
Optimizan o rendemento e os paquetes de máis de 9000 bytes: serán enormes marcos encapsulados para que os contedores se comuniquen entre si ou para operacións de copia de seguridade, creando instantáneas ou implantando estes mesmos contedores. Incluso os enderezos IP dinámicos non afectarán de ningún xeito o funcionamento de WireGuard no caso do escenario que describín.
Ben xogado. Implementación brillante e protocolo moi fino, case de referencia.
Pero simplemente non encaixa nun mundo fóra dun centro de datos que controlas por completo. Se corre o risco e comeza a usar WireGuard, terá que facer compromisos constantes no deseño e implementación do protocolo de cifrado.
Saída
É fácil para min concluír que WireGuard aínda non está listo.
Foi concibido como unha solución lixeira e rápida a unha serie de problemas coas solucións existentes. Desafortunadamente, polo ben destas solucións, sacrificou moitas funcións que serán relevantes para a maioría dos usuarios. É por iso que non pode substituír IPsec ou OpenVPN.
Para que WireGuard sexa competitivo, debe engadir polo menos unha configuración de enderezo IP e unha configuración de enrutamento e DNS. Obviamente, para iso están as canles cifradas.
A seguridade é a miña principal prioridade, e agora mesmo non teño motivos para crer que IKE ou TLS estean comprometidos ou rotos dalgún xeito. O cifrado moderno é compatible en ambos os dous, e foron probados por décadas de funcionamento. Que algo sexa máis novo non significa que sexa mellor.
A interoperabilidade é moi importante cando te comunicas con terceiros cuxas estacións non controlas. IPsec é o estándar de facto e é compatible en case todas as partes. E traballa. E non importa como se vexa, en teoría, WireGuard no futuro pode non ser compatible mesmo con diferentes versións de si mesmo.
Calquera protección criptográfica rómpese tarde ou cedo e, en consecuencia, debe ser substituída ou actualizada.
Negar todos estes feitos e querer cegamente usar WireGuard para conectar o teu iPhone á estación de traballo doméstica é só unha clase maxistral para meter a cabeza na area.
Fonte: www.habr.com