Jami w Rosji: problemy komunikatora P2P i rozwiązania techniczne

Jami w Rosji: techniczne bariery komunikatora P2P i rozwiązania architektoniczne

Zdecentralizowany komunikator Jami napotyka krytyczne problemy w rosyjskich sieciach z powodu CGNAT i blokad, co czyni bezpośrednie połączenia peer-to-peer zawodnymi. Pomimo technicznego potencjału, obecna implementacja protokołu ICE i zależność od serwerów TURN nie radzi sobie ze współczesnymi ograniczeniami sieciowymi. Ten artykuł oferuje inżynierski przegląd problemów i konkretne kroki w kierunku modernizacji architektury dla stabilnego działania.

Problemy połączeń P2P w rosyjskich sieciach

Główna niestabilność Jami wiąże się ze specyfiką infrastruktury dostawców internetu. Carrier Grade NAT (CGNAT), powszechnie stosowany przez operatorów mobilnych, pozbawia abonentów publicznych adresów IP, uniemożliwiając przychodzące połączenia. Szczególnie problematyczny jest symetryczny NAT, gdzie standardowe metody takie jak STUN i UDP hole punching często zawodzą.

Kluczowe ograniczenia sieciowe:

• Brak publicznych adresów IP użytkowników w sieciach mobilnych.
• Niska skuteczność protokołu ICE przy pracy przez CGNAT.
• Niedostępność publicznych serwerów TURN turn.jami.net na terenie Rosji.
• Łatwa detekcja ruchu TURN przez systemy DPI z powodu braku wsparcia DTLS/TLS.

Niedociągnięcia architektoniczne obecnej implementacji

Jami opiera się na elementach scentralizowanych, co przeczy jej zdecentralizowanej filozofii. Węzły rozruchowe DHT, niezbędne do wejścia do sieci, mogą być zablokowane, a serwery TURN tworzą pojedyncze punkty awarii. Ruch przez TURN zwiększa opóźnienia i jest podatny na blokady, co jest szczególnie krytyczne w warunkach rosyjskiej regulacji internetu.

Porównanie podejść do retransmisji:

• Obecny TURN: Scentralizowany serwer, łatwo blokowany, zwiększa latency.
• P2P-retransmisja: Wykorzystanie węzłów użytkowników z białymi IP, rozproszone obciążenie.
• Mesh-sieci: Dynamiczne routowanie przez kilka węzłów, maksymalna odporność na awarie.

Techniczne rozwiązania dla modernizacji Jami

Aby przezwyciężyć ograniczenia sieciowe, wymagane jest kompleksowe zaktualizowanie protokołów i architektury. Priorytetem powinno być wyeliminowanie zależności od TURN i ulepszenie mechanizmów nawiązywania bezpośrednich połączeń.

Poziom 1: Ulepszenie połączeń P2P

• Priorytetyzacja IPv6: Wymuszone użycie adresów IPv6 w kandydatach ICE do omijania NAT. W rosyjskich sieciach mobilnych IPv6 jest już aktywnie dystrybuowane, co może zapewnić bezpośrednie połączenie dla do 70% użytkowników.
• Agresywny UPnP: Zwiększenie prób mapowania portów i skrócenie interwałów pakietów keepalive do 15 sekund w celu utrzymania sesji NAT.
• Ulepszony ICE dla CGNAT: Implementacja mechanizmów inferencji portów do przewidywania zachowania symetrycznego NAT i nawiązywania bezpośrednich połączeń.

Poziom 2: Współczesne protokoły transportowe

Przejście na QUIC zamiast obecnego zestawu TCP/UDP zapewni:

• Lepsze działanie przez NAT dzięki wbudowanym keepalive i migracji połączeń.
• Multipleksowanie bez head-of-line blocking.
• Odporność na blokady DPI z powodu wbudowanego szyfrowania TLS 1.3.
• Zachowanie połączeń przy przełączaniu między Wi-Fi a sieciami mobilnymi.

Poziom 3: P2P-retransmisja przez relay peers

Wdrożenie mechanizmu, w którym węzły z białymi adresami IP działają jako retransmitery dla użytkowników za CGNAT:

• Dodanie nowego typu kandydata ICE peer_relay.
• Publikacja w DHT informacji o dostępności do retransmisji.
• End-to-end szyfrowanie ruchu nawet przy przechodzeniu przez pośrednie węzły.
• Samoorganizacja sieci: im więcej użytkowników z białymi IP, tym stabilniejszy system.

Poziom 4: Rozszerzone wykorzystanie DHT

Integracja libtorrent dla całkowicie zdecentralizowanej transmisji wiadomości tekstowych i plików:

• Wykorzystanie DHT nie tylko do sygnalizacji, ale i do rozpowszechniania danych.
• Eliminacja zależności od jakichkolwiek scentralizowanych serwerów dla nie-medialnego ruchu.
• Zwiększenie odporności na awarie sieci.

Poziom 5: Mesh-routowanie

Długoterminowa perspektywa — stworzenie nakładkowej mesh-sieci z dynamicznym routowaniem:

• Implementacja protokołów typu BATMAN lub OLSR.
• Automatyczne budowanie optymalnych ścieżek przez kilka węzłów.
• Zwiększanie stabilności sieci z każdym nowym uczestnikiem.

Poziom 6: Usunięcie TURN z bazy kodowej

Po wdrożeniu poprzednich poziomów TURN powinien być całkowicie wykluczony:

• Usunięcie kandydatów relay z protokołu ICE.
• Wykluczenie ustawień TURN z interfejsu użytkownika.
• Kompilacja PJSIP bez wsparcia TURN dla zmniejszenia powierzchni ataków.

Optymalizacja: Hole Punching z koordynatorem

Aby zminimalizować ruch przez retransmitery, można używać węzłów z białymi IP tylko jako koordynatorów do początkowego nawiązania połączenia. Po udanym hole punching retransmiter jest wykluczany z łańcucha, a użytkownicy przechodzą na czyste połączenie P2P. To podejście łączy niezawodność retransmisji z efektywnością bezpośrednich połączeń.

Co jest ważne

• CGNAT w rosyjskich sieciach mobilnych — główna przeszkoda dla połączeń P2P w Jami.
• Zależność od serwerów TURN tworzy podatności i zwiększa opóźnienia.
• Przejście na IPv6 i QUIC może rozwiązać większość problemów z NAT i blokadami.
• P2P-retransmisja przez relay peers zapewni zdecentralizowaną alternatywę dla TURN.
• Całkowite usunięcie TURN z architektury powinno być ostatecznym celem rozwoju projektu.

— Editorial Team