A medida que se nos nega cada vez máis o acceso a varios recursos da rede, o problema de evitar o bloqueo faise cada vez máis apremiante, o que significa que a pregunta "Como evitar o bloqueo máis rápido?" faise cada vez máis relevante.
Deixemos o tema da eficiencia en termos de ignorar as listas brancas de DPI para outro caso e simplemente comparemos o rendemento das populares ferramentas de bypass de bloques.
Atención: haberá moitas imaxes baixo spoilers no artigo.
Descargo de responsabilidade: este artigo compara o rendemento das solucións de proxy VPN populares en condicións próximas ás "ideais". Os resultados obtidos e descritos aquí non coinciden necesariamente cos teus resultados nos campos. Porque o número da proba de velocidade moitas veces non dependerá do poderoso que sexa a ferramenta de derivación, senón de como o acelera o teu provedor.
Metodoloxía
Adquiríronse 3 VPS a un provedor de nube (DO) en diferentes países do mundo. 2 nos Países Baixos, 1 en Alemaña. Seleccionouse o VPS máis produtivo (por número de núcleos) entre os dispoñibles para a conta baixo a oferta de créditos de cupón.
Un servidor privado iperf3 está despregado no primeiro servidor holandés.
No segundo servidor holandés, varios servidores de ferramentas de bypass de bloques están implantados un por un.
No VPS alemán está implantada unha imaxe de escritorio Linux (xubuntu) con VNC e un escritorio virtual. Esta VPN é un cliente condicional e varios clientes proxy VPN están instalados e lanzados nela á súa vez.
As medicións de velocidade realízanse tres veces, centrámonos na media, usamos 3 ferramentas: en Chromium mediante unha proba de velocidade web; en Chromium a través de fast.com; desde a consola a través de iperf3 a través de proxychains4 (onde precisa poñer o tráfico de iperf3 no proxy).
Unha conexión directa "cliente"-servidor iperf3 dá unha velocidade de 2 Gbps en iperf3, e un pouco menos en fastspeedtest.
Un lector curioso pode preguntar: "Por que non escolleches speedtest-cli?" e terá razón.
Speedtest-cli resultou ser pouco fiable e un xeito inadecuado de medir o rendemento, por razóns descoñecidas para min. Tres medicións consecutivas poderían dar tres resultados completamente diferentes ou, por exemplo, mostrar un rendemento moito maior que a velocidade do porto do meu VPS. Quizais o problema sexa a miña man, pero parecía imposible realizar investigacións con tal ferramenta.
En canto aos resultados dos tres métodos de medición (speedtest fastiperf), considero que os indicadores iperf son os máis precisos e fiables, e o fastspeedtest como referencia. Pero algunhas ferramentas de derivación non permitían completar 3 medicións a través de iperf3 e, nestes casos, pode confiar en speedtestfast.
proba de velocidade dá resultados diferentes
Kit de ferramentas
En total, probáronse 24 ferramentas de bypass diferentes ou as súas combinacións, para cada unha delas darei pequenas explicacións e as miñas impresións de traballar con elas. Pero, esencialmente, o obxectivo era comparar as velocidades de shadowsocks (e unha morea de ofuscadores diferentes para iso) openVPN e wireguard.
Neste material, non falarei en detalle da cuestión de "como ocultar o tráfico mellor para non ser desconectado", porque evitar o bloqueo é unha medida reactiva: adaptámonos ao que usa o censor e actuamos sobre esta base.
Descubrimentos
Strongswanipsec
Segundo as miñas impresións, é moi sinxelo de configurar e funciona de forma bastante estable. Unha das vantaxes é que é realmente multiplataforma, sen necesidade de buscar clientes para cada plataforma.
descarga - 993 Mbits; carga - 770 Mbits
Túnel SSH
Probablemente só os preguiceiros non escribiron sobre o uso de SSH como ferramenta de túnel. Unha das desvantaxes é a "muleta" da solución, é dicir. implementalo desde un cliente cómodo e bonito en todas as plataformas non funcionará. As vantaxes son un bo rendemento, non é necesario instalar nada no servidor.
descarga - 1270 Mbits; carga - 1140 Mbits
OpenVPN
OpenVPN probouse en 4 modos operativos: tcp, tcp+sslh, tcp+stunnel, udp.
Os servidores OpenVPN configuráronse automaticamente instalando streisand.
Polo que se pode xulgar, polo momento só o modo stunnel é resistente aos DPI avanzados. O motivo do aumento anormal do rendemento ao envolver openVPN-tcp en stunnel non me queda claro, as comprobacións fixéronse en varias execucións, en diferentes momentos e en diferentes días, o resultado foi o mesmo. Quizais isto se deba á configuración da pila de rede instalada ao implementar Streisand, escribe se tes algunha idea de por que é así.
openvpntcp: descarga - 760 Mbits; carga - 659 Mbits
openvpntcp+sslh: descarga - 794 Mbits; carga - 693 Mbits
openvpntcp+stunnel: descarga - 619 Mbits; carga - 943 Mbits
openvpnudp: descarga - 756 Mbits; carga - 580 Mbits
Openconnect
Non é a ferramenta máis popular para evitar bloqueos, está incluída no paquete Streisand, polo que decidimos probala tamén.
descarga - 895 Mbits; carga 715 mbps
Parabrisas
Unha ferramenta de publicidade popular entre os usuarios occidentais, os desenvolvedores do protocolo ata recibiron algunhas subvencións para o desenvolvemento de fondos de defensa. Funciona como un módulo do núcleo de Linux a través de UDP. Recentemente apareceron clientes para windowsios.
Foi concibido polo creador como unha forma sinxela e rápida de ver Netflix mentres non está nos Estados Unidos.
De aí os pros e os contras. Pros: protocolo moi rápido, relativa facilidade de instalación e configuración. Desvantaxes: o desenvolvedor non o creou inicialmente co obxectivo de evitar bloqueos graves e, polo tanto, wargard é facilmente detectado polas ferramentas máis sinxelas, incl. wireshark.
protocolo wireguard en wireshark
descarga - 1681 Mbits; carga 1638 mbps
Curiosamente, o protocolo warguard úsase no cliente tunsafe de terceiros, que, cando se usa co mesmo servidor warguard, dá resultados moito peores. É probable que o cliente de Windows wargard mostre os mesmos resultados:
tunsafeclient: descarga - 1007 Mbits; carga - 1366 Mbits
OutlineVPN
Outline é unha implementación dun servidor e cliente shadowox cunha interface de usuario fermosa e cómoda do rompecabezas de Google. En Windows, o cliente de contorno é simplemente un conxunto de envoltorios para os binarios shadowsocks-local (cliente shadowsocks-libev) e badvpn (binario tun2socks que dirixe todo o tráfico da máquina a un proxy local de socks).
Shadowsox foi unha vez resistente ao Gran Firewall de China, pero segundo as recentes críticas, este xa non é o caso. A diferenza de ShadowSox, fóra da caixa non admite conectar a ofuscación a través de complementos, pero isto pódese facer manualmente modificando o servidor e o cliente.
descarga - 939 Mbits; carga - 930 Mbits
SombrasR
ShadowsocksR é un fork dos Shadowsocks orixinais, escritos en Python. En esencia, é unha caixa de sombras á que están firmemente fixados varios métodos de ofuscación do tráfico.
Hai forks de ssR para libev e algo máis. O baixo rendemento débese probablemente á linguaxe do código. O shadowsox orixinal en python non é moito máis rápido.
shadowsocksR: descarga 582 mbits; carga 541 Mbits.
Shadowsocks
Unha ferramenta de desvío de bloques chinesa que aleatoriza o tráfico e interfire coa análise automática doutras formas marabillosas. Ata hai pouco, GFW non estaba bloqueado; din que agora só se bloquea se o relé UDP está activado.
Multiplataforma (hai clientes para calquera plataforma), admite traballar con PT semellante aos ofuscadores de Thor, hai varios ofuscadores propios ou adaptados a el, rápido.
Hai unha morea de implementacións de clientes e servidores shadowox, en diferentes idiomas. Nas probas, shadowsocks-libev actuou como servidor, diferentes clientes. O cliente Linux máis rápido resultou ser shadowsocks2 en marcha, distribuído como cliente predeterminado en Streisand, non podo dicir canto máis produtivo é shadowsocks-windows. Na maioría das probas posteriores, utilizouse shadowsocks2 como cliente. Non se fixeron capturas de pantalla que probaban shadowsocks-libev puros debido ao atraso obvio desta implementación.
shadowsocks2: descarga - 1876 mbits; carga - 1981 Mbits.
shadowsocks-rust: descarga - 1605 mbits; carga - 1895 Mbits.
Shadowsocks-libev: descarga - 1584 mbits; carga - 1265 Mbits.
Obfs simples
O complemento para shadowsox está agora en estado "depreciado", pero aínda funciona (aínda que non sempre ben). En gran parte suplantado polo complemento v2ray. Ofusca o tráfico baixo un websocket HTTP (e permítelle falsificar a cabeceira de destino, finxindo que non vas ver un pornhub, senón, por exemplo, o sitio web da Constitución da Federación Rusa) ou baixo pseudo-tls (pseudo). , debido a que non usa ningún certificado, os DPI máis sinxelos, como o nDPI gratuíto, detéctanse como "tls no cert". No modo tls, xa non é posible falsificar as cabeceiras).
Moi rápido, instalado desde o repositorio cun só comando, configurado de forma moi sinxela, ten unha función de failover incorporada (cando o tráfico dun cliente non simple-obfs chega ao porto que escoita simple-obfs, envíao ao enderezo onde especifique na configuración - deste xeito, pode evitar a comprobación manual do porto 80, por exemplo, simplemente redirixindo a un sitio web con http, así como o bloqueo mediante sondas de conexión).
shadowsockss-obfs-tls: descarga - 1618 mbits; carga 1971 Mbits.
shadowsockss-obfs-http: descarga - 1582 mbits; carga - 1965 Mbits.
Os simples obfs no modo HTTP tamén poden funcionar a través dun proxy inverso CDN (por exemplo, cloudflare), polo que para o noso provedor o tráfico parecerase ao tráfico HTTP en texto plano para cloudflare, isto permítenos ocultar un pouco mellor o noso túnel e ao mesmo tempo separa o punto de entrada e a saída do tráfico: o provedor ve que o teu tráfico vai cara ao enderezo IP CDN e os gustos extremistas nas imaxes colócanse neste momento desde o enderezo IP do VPS. Hai que dicir que é s-obfs a través de CF o que funciona de forma ambigua, non abrindo periodicamente algúns recursos HTTP, por exemplo. Polo tanto, non foi posible probar a carga usando iperf a través de shadowsockss-obfs+CF, pero a xulgar polos resultados da proba de velocidade, o rendemento está ao nivel de shadowsocksv2ray-plugin-tls+CF. Non estou adxuntando capturas de pantalla de iperf3, porque... Non debes confiar neles.
descarga (test de velocidade) - 887; carga (proba de velocidade) - 1154.
Descarga (iperf3) - 1625; cargar (iperf3) - NA.
v2ray-plugin
V2ray-plugin substituíu os obfs simples como o ofuscador "oficial" principal para as libs ss. A diferenza dos obfs simples, aínda non está nos repositorios e cómpre descargar un binario preensamblado ou compilalo vostede mesmo.
Admite 3 modos de funcionamento: por defecto, HTTP websocket (con soporte para spoofing encabezados do host de destino); tls-websocket (a diferenza de s-obfs, este é un tráfico tls completo, que é recoñecido por calquera servidor web proxy inverso e, por exemplo, permítelle configurar a terminación de tls en servidores cloudfler ou en nginx); quic - funciona a través de udp, pero desafortunadamente o rendemento de quic en v2rey é moi baixo.
Entre as vantaxes en comparación cos obfs simples: o complemento v2rey funciona sen problemas vía CF en modo HTTP-websocket con calquera tráfico, en modo TLS é tráfico TLS completo, require certificados para o seu funcionamento (por exemplo, de Let's encrypt ou self). -asinado).
shadowsocksv2ray-plugin-http: descarga - 1404 Mbits; carga 1938 Mbits.
shadowsocksv2ray-plugin-tls: descarga - 1214 Mbits; carga 1898 Mbits.
shadowsocksv2ray-plugin-quic: descarga - 183 Mbits; carga 384 Mbits.
Como xa dixen, v2ray pode establecer cabeceiras, e así podes traballar con el a través dun CDN de proxy inverso (cloudfler, por exemplo). Por unha banda, isto complica a detección do túnel, por outra banda, pode aumentar lixeiramente (e ás veces reducir) o atraso; todo depende da localización de vostede e dos servidores. CF está probando o traballo con quic, pero este modo aínda non está dispoñible (polo menos para as contas gratuítas).
shadowsocksv2ray-plugin-http+CF: descarga - 1284 Mbits; carga 1785 Mbits.
shadowsocksv2ray-plugin-tls+CF: descarga - 1261 Mbits; carga 1881 Mbits.
Capa
O fragmento é o resultado do desenvolvemento posterior do ofuscador GoQuiet. Simula o tráfico TLS e funciona a través de TCP. Polo momento, o autor lanzou a segunda versión do complemento, cloak-2, que é significativamente diferente da capa orixinal.
Segundo o programador, a primeira versión do complemento utilizou o mecanismo de reanudación da sesión tls 1.2 para falsificar o enderezo de destino de tls. Despois do lanzamento da nova versión (clock-2), elimináronse todas as páxinas wiki en Github que describen este mecanismo; non hai mención diso na descrición actual do cifrado de ofuscación. Segundo a descrición do autor, a primeira versión do fragmento non se usa debido á presenza de "vulnerabilidades críticas na criptografía". No momento das probas, só había a primeira versión da capa, os seus binarios aínda están en Github e, ademais de todo o demais, as vulnerabilidades críticas non son moi importantes, porque shadowsox cifra o tráfico do mesmo xeito que sen capa, e a cloac non ten ningún efecto na criptografía de shadowsox.
shadowsockscloak: descarga - 1533; carga - 1970 Mbits
Kcptun
usa kcptun como transporte e nalgúns casos especiais permite conseguir un maior rendemento. Desafortunadamente (ou afortunadamente), isto é moi relevante para os usuarios de China, algúns de cuxos operadores móbiles aceleran moito o TCP e non tocan UDP.
Kcptun ten fame de enerxía e carga facilmente 100 núcleos Zion ao 4 % cando o proba un cliente. Ademais, o complemento é "lento" e cando traballa a través de iperf1 non completa as probas ata o final. Vexamos a proba de velocidade no navegador.
shadowsockskcptun: descarga (test de velocidade) - 546 mbits; carga (test de velocidade) 854 Mbits.
Conclusión
Necesitas unha VPN sinxela e rápida para deter o tráfico de toda a túa máquina? Entón a túa elección é garda de guerra. Queres proxies (para tunelización selectiva ou separación de fluxos de persoas virtuais) ou é máis importante para ti ocultar o tráfico de bloqueos graves? A continuación, mira shadowbox coa ofuscación tlshttp. Queres estar seguro de que a túa Internet funcionará mentres Internet funcione? Elixe o tráfico de proxy a través de CDN importantes, bloqueando o que provocará o fallo da metade de Internet do país.
Táboa dinámica, ordenada por descarga
Fonte: www.habr.com