W miarę jak coraz bardziej ogranicza się nam dostęp do różnych zasobów w sieci, coraz bardziej aktualne staje się pytanie o to, jak omijać blokady, a więc pojawia się pytanie: „Jak szybciej omijać blokady?”.
Temat efektywności, z punktu widzenia omijania DPI, białych i czarnych list, pozostawimy na inną okazję, a po prostu porównamy wydajność popularnych narzędzi do omijania blokad.
Uwaga: W artykule w sekcjach pod spoilerami znajduje się wiele obrazków.
Zastrzeżenie: Niniejszy artykuł porównuje wydajność popularnych rozwiązań VPN i proxy w warunkach zbliżonych do „idealnych”. Wyniki uzyskane i opisane tutaj niekoniecznie muszą pokrywać się z Twoimi wynikami w rzeczywistości. Ponieważ liczba w teście prędkości często zależy nie od tego, jak wydajne jest narzędzie omijania, ale od tego, jak Twój dostawca go ogranicza lub blokuje.
Metodologia
U dostawcy chmurowego (DO) zakupiono 3 VPS-y w różnych krajach na świecie. 2 w Holandii, 1 w Niemczech. Wybrano najbardziej wydajne VPS (pod względem liczby rdzeni) spośród dostępnych dla konta za pośrednictwem kuponów kredytowych.
Na pierwszym holenderskim serwerze uruchomiono prywatny serwer iperf3.
Na drugim holenderskim serwerze kolejno uruchamiane są różne serwery narzędzi do omijania blokady.
Na niemieckim VPS-ie uruchomiono obraz desktopowego systemu Linux (Xubuntu) z VNC i wirtualnym pulpitem. Ten VPS jest warunkowym klientem i na nim kolejno instalowane i uruchamiane są różne klienci proxy i VPS.
Pomiar prędkości przeprowadzany jest co najmniej trzy razy, opieramy się na średniej, korzystając z 3 narzędzi: w Chromie przez web speed test; w Chromie przez fast.com; z konsoli przez iperf3 przez proxy chain (gdzie to konieczne, aby wkleić ruch iperf3 w proxy).
Bezpośrednie połączenie „klient”-serwer iperf3 osiąga prędkość 2 Gb/s w iperf3 i nieco mniej w fast speed teście.
Ciekawy czytelnik może zapytać: „Dlaczego nie wybrałeś speedtest-cli?” i będzie miał rację.
Test prędkości okazał się niewiarygodnym sposobem pomiaru przepustowości z nieznanych mi powodów. Trzy kolejne pomiary mogły dać trzy zupełnie różne wyniki, na przykład pokazać przepustowość znacznie wyższą niż prędkość portów w moim VPS. Może problem tkwi w moim braku umiejętności, ale prowadzenie badań za pomocą tego narzędzia wydało mi się niemożliwe.
Jeśli chodzi o wyniki trzech metod pomiaru (speedtest, fast, iperf), uważam, że dane z iperf są najbardziej dokładne, wiarygodne i rzetelne, podczas gdy speedtest fast jest jedynie referencyjny. Jednak niektóre narzędzia do omijania blokad nie pozwalały zakończyć trzech pomiarów za pomocą iperf3, w takich przypadkach można polegać na speedteście fast.
speedtest daje różne wyniki
Narzędzia
Łącznie przetestowano 24 różne narzędzia do omijania lub ich kombinacje, do każdego z nich dodam krótkie wyjaśnienia i moje wrażenia z pracy z nimi. Zasadniczo celem było porównanie szybkości shadowsocks (i wielu różnych obfuscatorów do niego), openVPN i wireguard.
W tym materiale nie będę szczegółowo omawiać kwestii „jak najlepiej ukryć ruch, aby nie został odłączony”, ponieważ omijanie blokad to działanie reaktywne — dostosowujemy się do tego, co robi cenzor, i działamy w oparciu o to.
Wyniki
Strongswan ipsec
Z moich obserwacji — bardzo łatwy w konfiguracji, działa wystarczająco stabilnie. Zaletą jest to, że jest naprawdę wieloplatformowy, bez potrzeby szukania klientów pod każdą platformę.
download — 993 mbits; upload — 770 mbits
SSH-tunel
O użyciu SSH jako narzędzia do tunelowania nie pisał chyba tylko leniwy. Z minusów — rozwiązanie jest „chwytliwe”, tzn. nie można go wdrożyć z wygodnego, ładnego klienta na każdej platformie. Z zalet — dobra wydajność, nie ma potrzeby instalowania czegokolwiek na serwerze.
download — 1270 mbits; upload — 1140 mbits
OpenVPN
OpenVPN był testowany w 4 trybach pracy: tcp, tcp+sslh, tcp+stunnel, udp.
Serwery OpenVPN zostały skonfigurowane automatycznie, instalacją streisand.
Na podstawie dostępnych informacji, obecnie tylko tryb pracy przez stunnel wydaje się być odporny na zaawansowane DPI. Powód anormalnego wzrostu przepustowości przy używaniu OpenVPN-TCP w stunnel nie jest mi jasny, testy były przeprowadzane w kilku turach, w różnym czasie i w różne dni, a wyniki były takie same. Może to być związane z ustawieniami stosu sieciowego ustalanymi podczas wdrażania Streisand, daj znać, jeśli masz pomysły, dlaczego tak jest.
openvpntcp: pobieranie — 760 mb/s; wysyłanie — 659 mb/s
openvpntcp+sslh: pobieranie — 794 mb/s; wysyłanie — 693 mb/s
openvpntcp+stunnel: pobieranie — 619 mb/s; wysyłanie — 943 mb/s
openvpnudp: pobieranie — 756 mb/s; wysyłanie — 580 mb/s
Openconnect
Nie jest to najpopularniejsze narzędzie do omijania blokad, wchodzi w skład pakietu Streisand, dlatego postanowiono je przetestować.
pobieranie — 895 mb/s; wysyłanie 715 mb/s
Wireguard
Hype'owe narzędzie, cieszące się popularnością wśród zachodnich użytkowników, twórcy protokołu zdobyli nawet pewne granty na rozwój od fundacji ochrony. Działa jako moduł jądra Linux, przez UDP. Od niedawna pojawiły się klienci dla Windows i iOS.
Zostało stworzone przez twórcę jako prosty i szybki sposób na oglądanie Netflixa z miejsca, które nie znajduje się w Stanach Zjednoczonych.
Stąd wyniki plusy i minusy. Plusy — bardzo szybki protokół, względna prostota instalacji i konfiguracji. Minusy — twórca pierwotnie nie stworzył go z myślą o omijaniu poważnych blokad, w związku z czym WireGuard łatwo jest wykryć najprostszymi narzędziami, w tym Wireshark.
protokół WireGuard w Wireshark
pobieranie — 1681 mb/s; wysyłanie 1638 mb/s
Co ciekawe, protokół WireGuard jest używany w zewnętrznym kliencie Tunsafe, który przy użyciu tego samego serwera WireGuard, daje zdecydowanie gorsze wyniki. Jest bardzo prawdopodobne, że klient WireGuard dla Windows będzie wykazywał podobne wyniki:
tunsafeclient: pobieranie — 1007 mb/s; wysyłanie — 1366 mb/s
OutlineVPN
Outline to implementacja serwera i klienta Shadowsocks z ładnym i wygodnym GUI od Google'owskiego Jigsaw. W systemie Windows klient Outline jest po prostu zestawem wrapperów dla binarek shadowsocks-local (klient shadowsocks-libev) oraz badvpn (binarek tun2socks, który kieruje cały ruch maszyny do lokalnego SOCKS proxy).
Kiedyś Shadowsocks był odporny na wielki chiński firewall, ale według najnowszych recenzji, już tak nie jest. W przeciwieństwie do Shadowsocks, nie obsługuje z pudełka połączeń z obfuskacją przez wtyczki, ale można to zrobić ręcznie, bawiąc się serwerem i klientem.
download — 939 mbits; upload — 930 mbits
ShadowsocksR
ShadowsocksR to fork oryginalnego Shadowsocks, napisanego w Pythonie. W zasadzie stanowi Shadowsocks, do którego na stałe dodano kilka metod obfuskacji ruchu.
Istnieją forki ssR na libev i innych. Niska przepustowość prawdopodobnie jest spowodowana językiem kodu. Oryginalny Shadowsocks w Pythonie nie jest dużo szybszy.
shadowsocksR: download 582 mbits; upload 541 mbits.
Shadowsocks
Chińskie narzędzie do omijania blokad, randomizujące ruch i innymi wspaniałymi metodami zakłócające analizę automatyczną. Do niedawna nie było blokowane przez GFW, mówi się, że teraz jest blokowane, tylko jeśli włącza się UDP relay.
Cross-platformowy (są klienci na każdą platformę), obsługuje pracę z PT w stylu torowych obfuskatorów, istnieje kilka własnych lub dostosowanych do niego obfuskatorów, szybki.
Jest mnóstwo implementacji klientów i serwerów Shadowsocks w różnych językach. W testach jako serwer występował shadowsocks-libev, klienci — różni. Najszybszym klientem Linux stał się shadowsocks2 na Go, dystrybuowany jako domyślny klient w Streisand, nie potrafię określić, jak dużo wydajniejszy jest shadowsocks-windows. W większości dalszych testów jako klient używano właśnie shadowsocks2. Zrzuty ekranu z testowaniem czystego shadowsocks-libev nie były robione, z powodu oczywistego opóźnienia tej realizacji.
shadowsocks2: download — 1876 mbits; upload — 1981 mbits.
shadowsocks-rust: download — 1605 mbits; upload — 1895 mbits.
Shadowsocks-libev: download — 1584 mbits; upload — 1265 mbits.
Simple-obfs
Wtyczka do Shadowsocks, obecnie w stanie "deprecjonowanym", ale wciąż działa (choć nie zawsze dobrze). W dużej mierze została wyparta przez wtyczkę v2ray-plugin. Obfuskacja ruchu może być pod HTTP-WebSocket (i pozwala na oszukiwanie nagłówków hostów docelowych, udając, że idziesz oglądać nie Pornhub, a na przykład stronę konstytucji RF) lub pod pseudo-TLS (pseudo, ponieważ nie używa żadnych certyfikatów, najprostsze DPI, jak darmowy nDPI, wykrywają jako "tls no cert". W trybie tls oszukiwanie nagłówków już nie jest możliwe).
Wystarczająco szybki, instalowany z repozytoriów za pomocą jednej komendy, bardzo prosto konfigurowany, ma wbudowaną funkcję failover (gdy na port, który nasłuchuje Simple-Obfs, przychodzi ruch od klienta, który nie korzysta z Simple-Obfs, przekierowuje go na adres wskazany w ustawieniach — w ten sposób można uniknąć ręcznej weryfikacji portu 80, po prostu przekierowując na stronę internetową przez HTTP oraz blokad przez connection-probe).
shadowsockss-obfs-tls: pobieranie — 1618 mbits; wysyłanie 1971 mbits.
shadowsockss-obfs-http: pobieranie — 1582 mbits; wysyłanie — 1965 mbits.
Simple-Obfs w trybie HTTP może również działać przez reverse proxy CDN (na przykład Cloudflare), w ten sposób dla naszego dostawcy ruch będzie wyglądał jak ruch HTTP w czystym tekście do Cloudflare, co pozwala lepiej ukryć nasz tunel, a także rozdzielić punkt wejścia i wyjścia ruchu — dostawca widzi, że twój ruch kieruje się do CDN, a ekstremistyczne lajki na obrazkach są zaznaczane w tym momencie z adresu IP VPS. adresu IP Trzeba powiedzieć, że właśnie Simple-Obfs przez CF działa niejednoznacznie, czasami nie otwierając niektórych zasobów HTTP, na przykład. Tak, przetestowanie uploadu przy użyciu iperf przez shadowsockss-obfs+CF się nie udało, ale sądząc po wynikach testu prędkości, przepustowość jest na poziomie shadowsocksv2ray-plugin-tls+CF. Nie dołączam zrzutów z iperf3, ponieważ na nich nie warto się opierać.
pobieranie (speedtest) — 887; wysyłanie (speedtest) — 1154.
Pobieranie (iperf3) — 1625; wysyłanie (iperf3) — NA.
v2ray-plugin
V2ray-plugin zastąpił Simple-Obfs jako główny „oficjalny” obfuscator dla ss-libev. W odróżnieniu od Simple-Obfs, nie jest jeszcze dostępny w repozytoriach, i trzeba albo pobrać wcześniej skompilowany binarny plik, albo skompilować samemu.
Obsługuje 3 tryby pracy: domyślny, HTTP-WebSocket (z obsługą spoofingu nagłówków hosta docelowego); TLS-WebSocket (w przeciwieństwie do Simple-Obfs to pełnoprawny ruch TLS, który jest rozpoznawany przez każdy serwer www/reverse proxy i na przykład umożliwia skonfigurowanie zakończenia TLS na serwerach Cloudflare lub w Nginx); QUIC — działa przez UDP, ale niestety wydajność QUIC w V2Ray jest bardzo niska.
Zalety w porównaniu do Simple-Obfs: w2ray-plugin bez problemu działa przez CF w trybie HTTP-WebSocket z dowolnym ruchem, w trybie TLS stanowi pełnoprawny ruch TLS, wymaga do działania certyfikatów (na przykład od Let’s Encrypt lub certyfikatów samopodpisanych).
shadowsocksv2ray-plugin-http: pobieranie — 1404 mbits; wysyłanie 1938 mbits.
shadowsocksv2ray-plugin-tls: pobieranie — 1214 mbits; wysyłanie 1898 mbits.
shadowsocksv2ray-plugin-quic: pobieranie — 183 mbits; wysyłanie 384 mbits.
Jak już wspomniałem, v2ray potrafi dodawać nagłówki, co umożliwia jego użycie za pośrednictwem reverse-proxy CDN (np. Cloudflare). Z jednej strony utrudnia to wykrycie tunelu, a z drugiej — może nieznacznie zwiększyć (a czasem zmniejszyć) opóźnienia — wszystko zależy od lokalizacji użytkownika i serwerów. Obecnie CF testuje pracę z quic, ale ten tryb jest na razie niedostępny (przynajmniej dla darmowych kont).
shadowsocksv2ray-plugin-http+CF: pobieranie — 1284 mbits; wysyłanie 1785 mbits.
shadowsocksv2ray-plugin-tls+CF: pobieranie — 1261 mbits; wysyłanie 1881 mbits.
Cloak
Cloak to wynik dalszego rozwoju obfuscatora GoQuiet. Symuluje ruch TLS, działając odpowiednio przez TCP. Obecnie autor wydał drugą wersję pluginu, cloak-2, która różni się znacznie od oryginalnego cloka.
Według informacji od twórcy, pierwsza wersja pluginu wykorzystywała mechanizm tls 1.2 resume session, aby podrobić adres docelowy dla tls. Po wydaniu nowej wersji (cloak-2) wszystkie strony wiki na GitHubie opisujące ten mechanizm zostały usunięte, a w aktualnym opisie szyfrowania obfuskacji nie ma takich odniesień. Z opisu autora wynika, że pierwsza wersja cloak nie jest już używana z powodu „krytycznych luk w kryptografii”. W momencie przeprowadzania testów dostępna była tylko pierwsza wersja cloaka, jej binaria wciąż znajdują się na GitHubie, lecz poza tym, krytyczne luki nie są istotne, ponieważ shadowsocks szyfruje ruch dokładnie tak samo, jak bez cloaka, a cloak nie wpływa na kryptografię shadowsocksa.
shadowsockscloak: pobieranie — 1533; wysyłanie — 1970 mbits
Kcptun
kcptun używa jako transportu i w niektórych szczególnych przypadkach pozwala osiągnąć wzrost przepustowości. Niestety (lub na szczęście) jest to w dużej mierze aktualne dla użytkowników z Chin, gdzie część operatorów mobilnych intensywnie ogranicza TCP, a UDP nie jest dotykane.
Kcptun jest niesamowicie zasobożerny, potrafi obciążyć w 100% 4 rdzenie przy testowaniu 1 klientem. Ponadto plugin jest „wolny”, a także przy pracy przez iperf3 nie kończy testów do końca. Skupiamy się na teście prędkości w przeglądarce.
shadowsockskcptun: pobieranie (speedtest) — 546 mbits; wysyłanie (speedtest) 854 mbits.
Podsumowanie
Potrzebujesz prostego, szybkiego VPN-a, aby zabezpieczyć cały ruch w urządzeniu? W takim razie wybierz waergard. Chcesz mieć proxy (do selektywnego tunelowania lub rozdzielania strumieni wirtualnych osób) czy ważniejsze jest dla Ciebie zafałszowanie ruchu przed poważnymi blokadami? Zobacz shadousocks z obfuskacją TLSHTTP. Chcesz mieć pewność, że Twój internet będzie działał, dopóki działa internet? Wybierz proxy ruchu przez ważne CDN, których blokada spowoduje, że połowa internetu w kraju przestanie działać.
tabela podsumowująca, sortowanie według pobierania
Źródło: habr.com
