A mesura que se'ns denega l'accés a diversos recursos de la xarxa, la qüestió de la possibilitat d'evitar el bloqueig és cada cop més urgent, la qual cosa significa que la pregunta "Com evitar el bloqueig més ràpid?" esdevé cada cop més rellevant.
Deixem el tema de l'eficiència pel que fa a la superació de les llistes blanques de DPI per a un altre cas, i simplement comparem el rendiment de les eines de bypass de blocs populars.
Atenció: hi haurà moltes imatges sota spoilers a l'article.
Exempció de responsabilitat: aquest article compara el rendiment de les solucions de proxy VPN populars en condicions properes a les "ideals". Els resultats obtinguts i descrits aquí no coincideixen necessàriament amb els vostres resultats als camps. Perquè el nombre de la prova de velocitat sovint no dependrà de la potència de l'eina de derivació, sinó de com l'accelera el vostre proveïdor.
Metodologia
Es van comprar 3 VPS a un proveïdor de núvol (DO) a diferents països del món. 2 als Països Baixos, 1 a Alemanya. El VPS més productiu (per nombre de nuclis) es va seleccionar entre els disponibles per al compte sota l'oferta de crèdits de cupó.
S'ha desplegat un servidor privat iperf3 al primer servidor holandès.
Al segon servidor holandès, es despleguen un per un diversos servidors d'eines de bypass de blocs.
Al VPS alemany es desplega una imatge d'escriptori de Linux (xubuntu) amb VNC i un escriptori virtual. Aquesta VPN és un client condicional i s'hi instal·len i s'inicien al seu torn diversos clients intermediaris VPN.
Les mesures de velocitat es realitzen tres vegades, ens centrem en la mitjana, fem servir 3 eines: en Chromium mitjançant una prova de velocitat web; a Chromium a través de fast.com; des de la consola mitjançant iperf3 mitjançant proxychains4 (on cal posar trànsit iperf3 al proxy).
Una connexió directa "client"-servidor iperf3 ofereix una velocitat de 2 Gbps en iperf3, i una mica menys en fastspeedtest.
Un lector curiós pot preguntar: "Per què no vas triar speedtest-cli?" i tindrà raó.
Speedtest-cli va resultar ser poc fiable i una manera inadequada de mesurar el rendiment, per raons desconegudes per a mi. Tres mesures consecutives podrien donar tres resultats completament diferents o, per exemple, mostrar un rendiment molt superior a la velocitat del port del meu VPS. Potser el problema és la meva mà mata, però semblava impossible dur a terme investigacions amb aquesta eina.
Pel que fa als resultats dels tres mètodes de mesura (speedtest fastiperf), considero que els indicadors iperf són els més precisos i fiables, i el fastspeedtest com a referència. Però algunes eines de bypass no permetien completar 3 mesures mitjançant iperf3 i, en aquests casos, podeu confiar en speedtestfast.
La prova de velocitat dóna resultats diferents
Kit d’eines
En total, es van provar 24 eines de bypass diferents o les seves combinacions, per a cadascuna d'elles donaré petites explicacions i les meves impressions de treballar amb elles. Però bàsicament, l'objectiu era comparar les velocitats dels shadowsocks (i un munt d'ofuscadors diferents) openVPN i wireguard.
En aquest material, no parlaré detalladament de la qüestió de "la millor manera d'amagar el trànsit per no ser desconnectat", perquè eludir el bloqueig és una mesura reactiva: ens adaptem al que fa servir el censor i actuem sobre aquesta base.
Troballes
Strongswanipsec
Segons les meves impressions, és molt fàcil de configurar i funciona de manera bastant estable. Un dels avantatges és que és realment multiplataforma, sense necessitat de buscar clients per a cada plataforma.
descàrrega - 993 Mbits; càrrega - 770 Mbits
Túnel SSH
Probablement només els ganduls no han escrit sobre l'ús de SSH com a eina de túnel. Un dels inconvenients és la "muleta" de la solució, és a dir. desplegar-lo des d'un client còmode i bonic a totes les plataformes no funcionarà. Els avantatges són un bon rendiment, no cal instal·lar res al servidor.
descàrrega - 1270 Mbits; càrrega - 1140 Mbits
OpenVPN
OpenVPN es va provar en 4 modes de funcionament: tcp, tcp+sslh, tcp+stunnel, udp.
Els servidors OpenVPN es van configurar automàticament instal·lant streisand.
Pel que es pot jutjar, de moment només el mode stunnel és resistent als DPI avançats. El motiu de l'augment anormal del rendiment en embolicar openVPN-tcp a stunnel no em queda clar, les comprovacions es van fer en diverses execucions, en diferents moments i en diferents dies, el resultat va ser el mateix. Potser això es deu a la configuració de la pila de xarxa instal·lada en desplegar Streisand, escriviu si teniu alguna idea per què és així.
openvpntcp: baixada - 760 Mbits; càrrega - 659 Mbits
openvpntcp+sslh: baixada - 794 Mbits; càrrega - 693 Mbits
openvpntcp+stunnel: baixada - 619 Mbits; càrrega - 943 Mbits
openvpnudp: baixada - 756 Mbits; càrrega - 580 Mbits
Openconnect
No és l'eina més popular per evitar bloquejos, està inclosa al paquet Streisand, així que vam decidir provar-la també.
descàrrega - 895 Mbits; pujar 715 Mbps
Protecció de cables
Una eina de bombo popular entre els usuaris occidentals, els desenvolupadors del protocol fins i tot van rebre algunes subvencions per al desenvolupament de fons de defensa. Funciona com a mòdul del nucli de Linux mitjançant UDP. Recentment, han aparegut clients per a windowsios.
Va ser concebut pel creador com una manera senzilla i ràpida de veure Netflix mentre no es troba als Estats Units.
D'aquí els pros i els contres. Avantatges: protocol molt ràpid, relativa facilitat d'instal·lació i configuració. Desavantatges: el desenvolupador no el va crear inicialment amb l'objectiu d'evitar bloquejos greus i, per tant, wargard es detecta fàcilment amb les eines més senzilles, incl. wireshark.
protocol wireguard a wireshark
descàrrega - 1681 Mbits; pujar 1638 Mbps
Curiosament, el protocol warguard s'utilitza al client tunsafe de tercers, que, quan s'utilitza amb el mateix servidor de warguard, dóna resultats molt pitjors. És probable que el client de Windows Wargard mostri els mateixos resultats:
tunsafeclient: descàrrega - 1007 Mbits; càrrega - 1366 Mbits
OutlineVPN
Outline és una implementació d'un servidor i client Shadowox amb una interfície d'usuari bonica i còmoda del trencaclosques de Google. A Windows, el client d'esquema és simplement un conjunt d'embolcalls per als binaris shadowsocks-local (client shadowsocks-libev) i badvpn (binari tun2socks que dirigeix tot el trànsit de la màquina a un proxy local de mitjons).
Shadowsox va ser una vegada resistent al Gran Tallafoc de la Xina, però segons les crítiques recents, aquest ja no és així. A diferència de ShadowSox, fora de la caixa no admet connectar l'ofuscament mitjançant connectors, però això es pot fer manualment modificant el servidor i el client.
descàrrega - 939 Mbits; càrrega - 930 Mbits
ShadocksocksR
ShadowsocksR és una bifurcació dels Shadowsocks originals, escrits en Python. En essència, es tracta d'una caixa d'ombres a la qual estan ben fixats diversos mètodes d'ofuscament del trànsit.
Hi ha bifurcacions de ssR per libev i alguna cosa més. El baix rendiment probablement es deu al llenguatge del codi. El shadowsox original a Python no és molt més ràpid.
shadowsocksR: descàrrega de 582 mbits; pujar 541 Mbits.
Shadowsocks
Una eina de bypass de bloc xinesa que aleatoritza el trànsit i interfereix amb l'anàlisi automàtica d'altres maneres meravelloses. Fins fa poc, GFW no estava bloquejat; diuen que ara només es bloqueja si el relé UDP està activat.
Multiplataforma (hi ha clients per a qualsevol plataforma), suporta el treball amb PT semblant als ofuscadors de Thor, n'hi ha diversos ofuscadors propis o adaptats a ell, ràpid.
Hi ha un munt d'implementacions de clients i servidors shadowox, en diferents idiomes. En les proves, shadowsocks-libev va actuar com a servidor, diferents clients. El client Linux més ràpid va resultar ser shadowsocks2 on go, distribuït com a client predeterminat a Streisand, no puc dir quant més productiu és shadowsocks-windows. En la majoria de proves posteriors, shadowsocks2 es va utilitzar com a client. Les captures de pantalla que van provar shadowsocks-libev purs no es van fer a causa del retard evident d'aquesta implementació.
shadowsocks2: descàrrega - 1876 Mbits; càrrega - 1981 Mbits.
shadowsocks-rust: descàrrega - 1605 mbits; càrrega - 1895 Mbits.
Shadowsocks-libev: descàrrega - 1584 Mbits; càrrega - 1265 Mbits.
Obfs simples
El connector per a shadowsox està ara en estat "amortitzat", però encara funciona (encara que no sempre està bé). En gran part substituït pel connector v2ray. Ofusca el trànsit sota un websocket HTTP (i us permet falsificar la capçalera de destinació, fent veure que no veureu un pornhub, sinó, per exemple, el lloc web de la Constitució de la Federació Russa) o sota pseudo-tls (pseudo). , com que no utilitza cap certificat, els DPI més simples, com ara el nDPI gratuït, es detecten com a "tls no cert". En el mode tls, ja no és possible falsificar les capçaleres).
Bastant ràpid, instal·lat des del repo amb una ordre, configurat de manera molt senzilla, té una funció de failover incorporada (quan el trànsit d'un client que no sigui simple-obfs arriba al port que escolta simple-obfs, el reenvia a l'adreça on especifiqueu a la configuració, així, d'aquesta manera, podeu evitar la comprovació manual del port 80, per exemple, simplement redirigint-vos a un lloc web amb http, així com el bloqueig mitjançant sondes de connexió).
shadowsockss-obfs-tls: descàrrega - 1618 mbits; pujar 1971 Mbits.
shadowsockss-obfs-http: baixada - 1582 mbits; càrrega - 1965 Mbits.
Els obfs simples en mode HTTP també poden funcionar mitjançant un servidor intermediari invers de CDN (per exemple, cloudflare), de manera que per al nostre proveïdor el trànsit semblarà al trànsit HTTP de text pla a cloudflare, això ens permet amagar una mica millor el nostre túnel i al mateix temps, separeu el punt d'entrada i la sortida del trànsit: el proveïdor veu que el vostre trànsit va cap a l'adreça IP del CDN i en aquest moment es col·loquen els gustos extremistes a les imatges des de l'adreça IP del VPS. Cal dir que és s-obfs a través de CF el que funciona de manera ambigua, periòdicament sense obrir alguns recursos HTTP, per exemple. Per tant, no va ser possible provar la càrrega amb iperf mitjançant shadowsockss-obfs+CF, però a jutjar pels resultats de la prova de velocitat, el rendiment és al nivell de shadowsocksv2ray-plugin-tls+CF. No adjunto captures de pantalla d'iperf3, perquè... No hauríeu de confiar en ells.
descàrrega (prova de velocitat) - 887; càrrega (prova de velocitat) - 1154.
Descarrega (iperf3) - 1625; càrrega (iperf3) - NA.
v2ray-plugin
V2ray-plugin ha substituït els obfs simples com a ofuscador "oficial" principal per a les biblioteques ss. A diferència dels obfs simples, encara no es troba als repositoris, i cal que descarregueu un binari preassemblat o que el compileu vosaltres mateixos.
Admet 3 modes de funcionament: per defecte, websocket HTTP (amb suport per a la falsificació de capçaleres de l'amfitrió de destinació); tls-websocket (a diferència de s-obfs, aquest és un trànsit tls complet, que és reconegut per qualsevol servidor web proxy invers i, per exemple, us permet configurar la terminació de tls als servidors cloudfler o a nginx); quic - funciona mitjançant udp, però malauradament el rendiment de quic a v2rey és molt baix.
Entre els avantatges en comparació amb obfs simples: el connector v2rey funciona sense problemes via CF en mode HTTP-websocket amb qualsevol trànsit, en mode TLS és trànsit TLS complet, requereix certificats per al funcionament (per exemple, de Let's encrypt o self -signat).
shadowsocksv2ray-plugin-http: baixada - 1404 Mbits; pujar 1938 Mbits.
shadowsocksv2ray-plugin-tls: baixada - 1214 Mbits; puja 1898 Mbits.
shadowsocksv2ray-plugin-quic: baixada - 183 Mbits; pujar 384 Mbits.
Com ja he dit, v2ray pot establir capçaleres i, per tant, podeu treballar-hi mitjançant un CDN de proxy invers (cloudfler, per exemple). D'una banda, això complica la detecció del túnel, d'altra banda, pot augmentar lleugerament (i de vegades reduir) el retard; tot depèn de la ubicació de vostè i dels servidors. CF està provant de treballar amb quic, però aquest mode encara no està disponible (almenys per als comptes gratuïts).
shadowsocksv2ray-plugin-http+CF: baixada - 1284 Mbits; pujar 1785 Mbits.
shadowsocksv2ray-plugin-tls+CF: baixada - 1261 Mbits; puja 1881 Mbits.
Capa
El fragment és el resultat del desenvolupament posterior de l'ofuscator GoQuiet. Simula el trànsit TLS i funciona mitjançant TCP. De moment, l'autor ha llançat la segona versió del connector, cloak-2, que és significativament diferent de la capa original.
Segons el desenvolupador, la primera versió del connector va utilitzar el mecanisme de reinici de sessió tls 1.2 per falsificar l'adreça de destinació de tls. Després del llançament de la nova versió (clock-2), es van suprimir totes les pàgines wiki de Github que descriuen aquest mecanisme; no hi ha cap menció a la descripció actual del xifratge per ofuscació. Segons la descripció de l'autor, la primera versió del fragment no s'utilitza a causa de la presència de "vulnerabilitats crítiques en cripto". En el moment de les proves, només hi havia la primera versió de la capa, els seus binaris encara es troben a Github i, a més de tota la resta, les vulnerabilitats crítiques no són molt importants, perquè shadowsox xifra el trànsit de la mateixa manera que sense una capa, i el cloac no té cap efecte en la criptografia de shadowsox.
shadowsockscloak: descàrrega - 1533; càrrega - 1970 Mbits
Kcptun
utilitza kcptun com a transport i en alguns casos especials permet aconseguir un major rendiment. Malauradament (o afortunadament), això és molt rellevant per als usuaris de la Xina, alguns dels operadors mòbils dels quals limiten molt el TCP i no toquen UDP.
Kcptun té fam d'energia i carrega fàcilment 100 nuclis Zion al 4% quan el prova 1 client. A més, el connector és "lent", i quan treballa amb iperf3 no completa les proves fins al final. Fem una ullada a la prova de velocitat al navegador.
shadowsockskcptun: descàrrega (prova de velocitat) - 546 Mbits; càrrega (prova de velocitat) 854 Mbits.
Conclusió
Necessites una VPN senzilla i ràpida per aturar el trànsit de tota la teva màquina? Llavors la teva elecció és guàrdia. Voleu servidors intermediaris (per a túnels selectius o separació de fluxos de persones virtuals) o és més important per a ofuscar el trànsit d'un bloqueig greu? A continuació, mireu shadowbox amb l'ofuscació tlshttp. Voleu estar segur que la vostra Internet funcionarà mentre Internet funcioni? Trieu el trànsit intermediari a través de CDN importants, el bloqueig que comportarà el fracàs de la meitat d'Internet al país.
Taula dinàmica, ordenada per descàrrega
Font: www.habr.com