Niski transfer przy połączeniu z dyskiem sieciowym przez VPN (np. WireGuard) z wykorzystaniem protokołu SMB to klasyczny problem. Wielu użytkowników obwinia za to przepustowość łącza, jednak w rzeczywistości jest to „wąskie gardło” samego protokołu. SMB (Server Message Block) nie został zaprojektowany do pracy przez Internet (publiczną sieć), lecz do lokalnych sieci LAN.
W tym artykule przyjrzymy się, dlaczego tak się dzieje, jak to naprawić i w jaki sposób skonfigurować środowisko NAS oparte na FreeBSD oraz ZFS, aby wycisnąć z niego maksymalną wydajność i żywotność.
Dlaczego SMB jest „wolne” przez VPN?
SMB jest protokołem bardzo „gadatliwym”. Przy każdej operacji plikowej (np. otwarcie pliku, zapisanie porcji danych) klient wysyła żądanie i musi czekać na potwierdzenie z serwera, zanim wyśle kolejne.
Problem opóźnień (Ping): Każde potwierdzenie to czas podróży pakietu. Jeśli opóźnienie do serwera wynosi 15 ms, każda wymiana informacji między systemem Windows a serwerem Samba zajmuje co najmniej 15 ms. Przy tysiącach małych operacji (np. sprawdzanie atrybutów, listowanie folderów) te milisekundy sumują się do sekund, drastycznie obniżając transfer.
Narzut VPN (Fragmentacja): WireGuard jest niezwykle szybki, ale enkapsulacja (pakowanie pakietów SMB w pakiety UDP WireGuarda) dodaje swój narzut. Przy domyślnym lub źle dobranym współczynniku MTU powoduje to fragmentację pakietów. Jest to najczęstszy powód, dla którego transfer potrafi spaść do poziomu zaledwie kilkuset KB/s.
Jak naprawić niskie transfery SMB w systemie Windows?
Krok A: Optymalizacja MTU (Kluczowe!)
Domyślne MTU w WireGuard (1420 bajtów) często okazuje się zbyt duże dla ruchu SMB wewnątrz tunelu.
Rozwiązaniem jest obniżenie MTU w konfiguracji WireGuard (zarówno na serwerze, jak i na kliencie) do wartości 1360 lub nawet 1300. Mniejsze pakiety nie będą dzielone na pół przez routery po drodze, co eliminuje retransmisje – głównego winowajcę spadków prędkości.
Krok B: Wyłączenie podpisywania SMB (SMB Signing)
Windows dla bezpieczeństwa domyślnie podpisuje każdy pakiet SMB. Przesyłanie takich pakietów przez szyfrowany już tunel VPN generuje podwójny narzut na procesor i dodaje opóźnienia.
Aby odciążyć procesor i przyspieszyć transfer, uruchom program PowerShell jako administrator na stacji roboczej i wpisz:
Set-SmbClientConfiguration -RequireSecuritySignature $falseKrok C: Włączenie SMB Multichannel
Jeśli system Windows oraz Samba na serwerze obsługują protokół SMB w wersji 3.x, warto upewnić się, że funkcja Multichannel jest aktywna. W Windows włączysz ją poleceniem:
Set-SmbClientConfiguration -EnableMultichannel $true(Należy pamiętać, aby w pliku konfiguracyjnym serwera smb4.conf również nie blokować tego mechanizmu).
Krok D: Diagnostyka i narzędzia alternatywne
Zanim zaczniesz przebudowywać serwer, zdiagnozuj, gdzie leży problem:
Test Iperf3: Zainstaluj iperf3. Uruchom go na serwerze (iperf3 -s) i przetestuj z klienta Windows (iperf3 -c [IP_SERWERA]). Jeśli wynik oscyluje w granicach możliwości Twojego łącza, infrastruktura jest idealna, a problemem jest wyłącznie protokół SMB.
Rozwiązania alternatywne: Jeśli transfery nadal nie satysfakcjonują, warto pogodzić się z faktem, że SMB źle znosi wysokie opóźnienia. Do pracy zdalnej z plikami często lepiej sprawdza się SFTP (np. WinSCP, FileZilla) lub Rclone. Jeśli zależy Ci na mapowaniu dysku w Windows, użyj narzędzi takich jak Raidrive, Mountain Duck lub Rclone Mount (–vfs-cache-mode full). Wykorzystują one pod spodem wydajniejsze na opóźnienia protokoły (WebDAV/SFTP), jedynie „udając” przed systemem dysk lokalny.
Realia sieci LAN vs VPN: Czego się spodziewać?
Gdyby serwer przenieść z odległej serwerowni do szafy obok (sieć LAN), opóźnienia spadłyby z np. 15 ms do 0.5 ms. Różnica w prędkości byłaby kolosalna. W fizyce sieci rządzi tzw. Bandwidth-Delay Product (BDP). Przy mniejszym pingu protokół SMB jest w stanie wykonać 30-krotnie więcej cykli „pytanie-odpowiedź” w ciągu sekundy. W takiej konfiguracji transfer z łatwością wysyciłby możliwości łącza 1 Gbps (ok. 110 MB/s).
W przypadku połączeń przez VPN (WireGuard), osiągnięcie 60 – 100 MB/s (ok. 480 – 800 Mbps) to wynik wybitny. Taka prędkość jest w „złotym punkcie” – pozwala na bardzo komfortową pracę, rzadko występują przy niej zatory procesora, a dyski nie są katowane ciągłym, maksymalnym obciążeniem.
Zarządzanie dyskami w środowisku NAS (FreeBSD i ZFS)
W profesjonalnym środowisku, zwłaszcza przy obsłudze wielu klientów (multi-tenancy) lub architekturze opartej na wirtualnych środowiskach (jails), odpowiednie zarządzanie przestrzenią dyskową to klucz do wydajności i żywotności sprzętu.
SSD SATA czy HDD?
Dzięki krótkiemu czasowi dostępu, nośniki SSD (SATA/NVMe) bezapelacyjnie wygrywają w starciu z gadatliwym protokołem SMB. Są niewrażliwe na tysiące małych operacji (IOPS). Tradycyjne dyski HDD przy wielu użytkownikach wymuszają ciągły ruch głowic (disk thrashing), co mocno obniża wydajność. HDD nadają się idealnie na wielkie magazyny danych (np. filmy), ale system i mniejsze udziały powinny opierać się na dyskach półprzewodnikowych.
Jak zoptymalizować ZFS, by „nie mielić” dysków?
System plików ZFS udostępnia potężne mechanizmy ochrony i przyspieszania nośników:
ZIL/SLOG na NVMe: Buforowanie synchronicznych zapisów na super-szybkim dysku NVMe to świetne rozwiązanie, ale nie należy zużywać takich dysków na zrzuty zwykłych logów (/var/log) czy katalogi tymczasowe (/tmp). Lepiej przenieść je do pamięci operacyjnej (tmpfs).
Wyłączenie atime (atime=off): Domyślnie system ZFS aktualizuje metadane przy każdym odczycie pliku (zapisując czas dostępu). W środowisku NAS generuje to niepotrzebne operacje zapisu. Komenda zfs set atime=off zroot/nas_data/ potrafi zredukować ilość zapisów na dysku o 30-50%.
Dobór Recordsize: Dla multimediów i wielkich archiwów warto ustawić parametr na recordsize=1M. Dla dokumentów i ogólnego zastosowania optymalna pozostaje domyślna wartość 128K. Zmniejsza to fragmentację i ilość koniecznych modyfikacji bloków danych.
ZFS ARC (Magia pamięci RAM): Największą siłą ZFS jest używanie wolnej pamięci RAM jako inteligentnego bufora odczytu (ARC). W scenariuszu NAS-a na FreeBSD często bywa tak, że dyski systemowe „odpoczywają”, ponieważ większość często używanych plików serwowana jest bezpośrednio z błyskawicznej pamięci RAM.
Bezpieczeństwo bez utraty wydajności (Szyfrowanie sprzętowe)
Mitem jest obawa, że pełne szyfrowanie serwera „zabije” jego wydajność. To prawda, ale tylko w przypadku tanich, konsumenckich urządzeń. W nowoczesnej architekturze, wykorzystującej sprzęt serwerowy (np. z procesorami Intel Xeon), szyfrowanie jest w zasadzie darmowe sprzętowo.
AES-NI: Jeśli Twój procesor wspiera instrukcje AES-NI, to szyfrowanie tunelu VPN oraz dysków delegowane jest bezpośrednio do układu sprzętowego. Procesor główny jest z tego obowiązku całkowicie odciążony.
ZFS Native Encryption: Natywne szyfrowanie (AES-256-GCM) odbywa się na poziomie bloków, tuż przed zapisem danych na fizyczny dysk. System ZFS optymalizuje ten proces w taki sposób, że najpierw bardzo szybko kompresuje dane (algorytm LZ4), a dopiero mniejszą paczkę danych szyfruje.
W efekcie uzyskujemy potężną architekturę:
Dane w locie: Szyfrowane wewnątrz tunelu (WireGuard).
Dane na dysku: Szyfrowane (ZFS Encryption).
Wydajność: Maksymalna, dzięki AES-NI i kompresji.
Zaawansowany tuning Samby
Na koniec – jeśli Twój serwer posiada sporą ilość pamięci RAM i chcesz wycisnąć z Samby absolutne maksimum pod kątem przesyłu dużych plików (np. wideo), warto zmodyfikować sekcję [global] w pliku konfiguracyjnym serwera:
[global]
# Konfiguracja podstawowa i optymalizacja gniazd TCP...
# Pozwala na przesyłanie większych bloków danych w jednym „strzale”
read raw = Yes
write raw = Yes
# Kopiowanie danych bezpośrednio z systemu plików do karty sieciowej (omijając przestrzeń użytkownika)
use sendfile = YesPodsumowanie
Optymalizacja dysków sieciowych działających przez połączenia VPN nie polega na jednym, magicznym przełączniku. To proces inżynieryjny, który wymaga zrozumienia specyfiki działania protokołów.
Dostosowanie MTU dla sieci WireGuard i odciążenie systemu Windows z narzutu szyfrowania SMB, to pierwsze kroki na drodze do stabilności. Prawdziwa moc drzemie jednak w odpowiedniej konstrukcji serwera bazowego. Architektura oparta o system FreeBSD, system plików ZFS, sprzętowe szyfrowanie AES-NI oraz prawidłowy podział ról dysków SSD i pamięci RAM (ARC) pozwala stworzyć serwer NAS najwyższej klasy. Takie środowisko gwarantuje potężną stabilność, pełne bezpieczeństwo danych i żywotność liczoną w latach, deklasując większość „pudełkowych” rozwiązań komercyjnych.