Czy niska przepustowość VPN to problem entropii? Zwykle nie

Niska przepustowość przez tunel i maszyna zawieszona w oczekiwaniu na liczby losowe dają bardzo różne doświadczenia, ale trafiają pod tę samą skargę. Jedno objawia się jako pauza, zanim cokolwiek zadziała. Drugie objawia się jako połączenie, które działa i powoli przenosi dane, dopóki je obserwujesz. Ustalenie, które masz, zajmuje dziesięć minut i oszczędza tydzień zgadywania.

Dwa objawy, które wyglądają podobnie

Usługa, która zawiesza się po świeżym starcie, zanim przyjmie choć jedno połączenie, na coś czeka. Tunel, który szybko się zestawia, a potem przesyła z ułamkiem oczekiwanej szybkości, jest ograniczany przez coś innego. Słowo szyfrowanie pojawia się w obu historiach, dlatego są łączone. Rozdziel je, zanim dotkniesz pliku konfiguracyjnego.

Umieść znaczniki czasu wokół startu, uwierzytelniania, ponownego uzgadniania kluczy i samego transferu. Długie opóźnienie, zanim tunel stanie się użyteczny, nie jest niską stałą szybkością, a uśrednienie obu w jedną liczbę niszczy dowód.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

Pierwsze dwa polecenia umieszczają pracę startową na osi czasu. Trzecie wypisuje wartość księgowania entropii jądra, która jest przydatna jako pojedynczy punkt danych i bezużyteczna jako miernik przepustowości.

Jak naprawdę wygląda oczekiwanie na liczby losowe

Żądanie bezpiecznych losowych bajtów może się zablokować, dopóki jądro nie zainicjuje swojego źródła losowości. Ma to największe znaczenie na maszynach wirtualnych i małych płytach wbudowanych wczesnym etapie startu, gdy zebrano niewiele szumu otoczenia. Nie wynika z tego, że każdy zaszyfrowany bajt zużywa świeżą entropię.

Nowoczesne generatory zasiewa się raz, a potem wytwarzają wyjście z deterministycznej konstrukcji, dosiewając się według własnego harmonogramu. Przesył masowy nie opróżnia puli bajt po bajcie, więc niska wartość puli podczas wolnego transferu niczego nie dowodzi o przyczynie.

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

Pierwsze polecenie pokazuje, czy proces siedzi w wywołaniu liczby losowej, gdy patrzysz. Drugie pokazuje własne komunikaty inicjalizacyjne jądra i właśnie tam wczesny zator startowy staje się widoczny.

Zapisz wersję jądra i bibliotekę, z którą usługa faktycznie się linkuje, bo zachowanie różni się między implementacjami i między wydaniami. Ślad pobrany po odzyskaniu zwykle całkowicie pomija pauzę.

Jak naprawdę wygląda utrzymująca się powolność

Tunel, który przez cały czas przesyła powoli, jest ograniczany przez ścieżkę danych. Jeden wysycony wątek, utrata zewnętrznych pakietów, retransmisje lub pełne kolejki gniazd każdy tworzy ten wzorzec, a każdy ma własną poprawkę. Zagregowany procent CPU ukrywa jeden zajęty wątek, a to najczęstszy błąd odczytu. Spójrz na czas na wątek, zanim spojrzysz na całkowite obciążenie.

Mierz w obu kierunkach z porównywalną podstawą i obserwuj liczniki interfejsu, a nie raport samej aplikacji.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

Pierwsze polecenie pokazuje stan kolejki i przeciążenia dla jednego peera. Drugie i trzecie zgłaszają odrzucenia i retransmisje na stosie i na interfejsie, gdzie przyczyna zwykle pojawia się pierwsza.

Wybierz poprawkę dla zmierzonego wąskiego gardła

Jeśli dowody wskazują na wczesną inicjalizację przy starcie, spójrz na wspieraną przez platformę ścieżkę zasiewania, która na maszynie wirtualnej może obejmować dostarczone przez hosta urządzenie losowe. Obraz ziarna skopiowany bez zmian do wielu gości nie zastępuje niezależnej inicjalizacji.

Jeśli dowody wskazują na ścieżkę danych, dostrój to, na co wskazują liczniki. Rozmiary buforów pomagają, gdy kolejki się przelewają, i nic nie robią, gdy jeden wątek jest wysycony. Instalowanie demona entropii, aby podnieść licznik, nie jest naprawą przepustowości, a zmiana założeń zasiewania, by wykres wyglądał lepiej, wymienia właściwość bezpieczeństwa na liczbę.

Zaakceptuj zmianę tylko wtedy, gdy ten sam pomiar poprawia się w tych samych warunkach. Większy licznik nie jest wynikiem; krótsze zmierzone oczekiwanie lub szybszy transfer z ustaloną przyczyną jest wynikiem.