Wpis z mikrobloga

Czy ktoś z was używa #torrent przez #vpn na #upc? Działa wam bez problemu? Od jakiegoś czasu mam taką dziwną sytuację, że gdy seeduję z jednego komputera (NAS) to wszystkie inne komputery w sieci lokalnej zaczynają łapać niebotycznie wielkie pingi i gubić połowę pakietów (względem reszty świata). Dziwność polega na tym, że jeśli wyłączę VPNa i seeduję "bez gumy" to wszystko wszystkim działa idealnie - przy tych samych prędkościach uploadu (1.5 MB/s). Ktoś wie, dlaczego tak się może dziać?
#siecikomputerowe (mam nadzieję, że nie spam)

Przykładowy ping z mojego PC do wykop.pl gdy ruch z NASa leci przez VPN (PrivateInternetAccess):

Badanie wykop.pl [51.83.238.216] z 32 bajtami danych:
Odpowiedź z 51.83.238.216: bajtów=32 czas=612ms TTL=51
Upłynął limit czasu żądania.
Odpowiedź z 51.83.238.216: bajtów=32 czas=386ms TTL=51
Upłynął limit czasu żądania.
Odpowiedź z 51.83.238.216: bajtów=32 czas=780ms TTL=51
Upłynął limit czasu żądania.
Odpowiedź z 51.83.238.216: bajtów=32 czas=532ms TTL=51
Upłynął limit czasu żądania.
Odpowiedź z 51.83.238.216: bajtów=32 czas=450ms TTL=51
Upłynął limit czasu żądania.
Statystyka badania ping dla 51.83.238.216:
Pakiety: Wysłane = 10, Odebrane = 5, Utracone = 5
(50% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
Minimum = 386 ms, Maksimum = 780 ms, Czas średni = 552 ms

Po wyłączeniu VPNa i puszczeniu ruchu wolno:

Badanie wykop.pl [51.83.238.216] z 32 bajtami danych:
Odpowiedź z 51.83.238.216: bajtów=32 czas=27ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=56ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=68ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=37ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=59ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=46ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=20ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=14ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=17ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=27ms TTL=51
Statystyka badania ping dla 51.83.238.216:
Pakiety: Wysłane = 10, Odebrane = 10, Utracone = 0
(0% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
Minimum = 14 ms, Maksimum = 68 ms, Czas średni = 37 ms
  • 36
@zakowskijan72: Testowałem prosty upload wysyłając 500 MB plik na google drive (test z peceta, nie mam pomysłu jak to zrobić z tego samego FreeNASa bo tam tylko konsola, curl i wget) i było wszystko okej. Jeśli chodzi o sam download to zaraz kliknę.

Z ciekawości, jaka to różnica czy tunel idzie po TCP czy UDP?
@d1sconn3cted: Okej ale to by znaczyło, że problem jest po stronie albo mojego NASa (który nie wyrabia z szyfrowaniem i pakowaniem danych do tunelu) albo providera VPN. A to nie tłumaczy, dlaczego inne komputery w mojej sieci lokalnej łapią nagle sekundowe pingi.
Z ciekawości, jaka to różnica czy tunel idzie po TCP czy UDP?

@salad_fingers: Niuanse związane z zarządzaniem połączeniem. Pod TCP połączeniem zarządza stos TCP systemu operacyjnego (pilnuje powtórzeń i potwierdzeń pakietów oraz kolejności danych), UDP jest prostszy i tego wszystkiego musi "pilnować" sama aplikacja, ale w praktyce przy dużych przepustowościach i stabilnym połączeniu UDP może być szybszy.
A to nie tłumaczy, dlaczego inne komputery w mojej sieci lokalnej łapią nagle sekundowe pingi.


@salad_fingers: to może inaczej bo o tym nie napisałeś, gdzie się zaczyna tunel, na NASie czy na routerze? Czyli czy tylko NAS idzie po tunelu czy cała sieć idzie po tunelu
@d1sconn3cted: Ok, w poniższej konfiguracji mam pingi po milion:

NAS -> VPN -> router -> świat
PC -> router -> świat

a w takiej jest idealnie i przyjemnie:
NAS -> router -> świat
PC -> router -> świat

@zakowskijan72: Chyba chodzi o jakikolwiek transfer przez tunel. Ograniczyłem upload do 100 kilo, puściłem download (na razie mam 600 kbps), obok tego prostym wgetem pobieram obraz xubuntu z Niemiec i jest syf.
Pod TCP połączeniem zarządza stos TCP systemu operacyjnego (pilnuje powtórzeń i potwierdzeń pakietów oraz kolejności danych), UDP jest prostszy i tego wszystkiego musi "pilnować" sama aplikacja


@zakowskijan72: w UDP pakiety nie mają numerów sekwencyjnych także nie ma czego pilnować, tak samo nie istnieje ACK czyli potwierdzanie odebrania pakietu. To typowe „wyślij i zapomnij”. Jak pakiety UDP dojdą w złej kolejności, jest utrata danych - system ani aplikacja nie są w stanie
Jak pakiety UDP dojdą w złej kolejności, jest utrata danych - system ani aplikacja nie są w stanie tego skorygować.


@kwitnaca-wisnia: to akurat nie prawda. Jeżeli aplikacje mają zaimplementowane taki mechanizm to są w stanie ułożyć pakiety UDP w poprawnej kolejności. Np. apka w danych na początku wrzuca swoje numerowanie pakietów i przy odbiorze sprawdza ich kolejność
@zakowskijan72: Mam domyślne ustawienie (1500), nigdy tego nie ruszałem bo aż tak się nie znam (poza tym, podstawowa konfiguracja działała przez ~2 lata bez problemów to nie ruszałem, dopiero od miesiąca mi się pieprzy). Zmniejszyć mogę na interfejsie głównym ale minimalna wartość to 1492 więc nie sądzę, że te 8 bajtów coś zmieni.

Czy jest możliwe, że to wina #upc? Nie wiem, że jakąś inspekcję pakietów robią czy jakiś QoS
w UDP pakiety nie mają numerów sekwencyjnych także nie ma czego pilnować

@kwitnaca-wisnia: Kolego, wiesz, że dzwonią, ale nie wiesz, w którym kościele.

Jak pakiety UDP dojdą w złej kolejności, jest utrata danych - system ani aplikacja nie są w stanie tego skorygować.

Otóż aplikacja może operować własnym protokołem na warstwie UDP, i owszem, może sobie w tym protokole nadawać numery i korygować, a także wysyłać potwierdzenia. Wszystko po UDP. Pisałem
@salad_fingers: Minimalna wartość to 1492? Powinieneś bez problemu móc ustawić np. 1000.

Czy jest możliwe, że to wina #upc?

Jest możliwe. Co prawda raczej inspekcji pakietów Ci nie zrobią - po to jest VPN, żeby węzły "po drodze" nie zaglądały w garnki, ale sam fakt, że adresatem pakietu jest węzeł VPN już jest łatwy do zweryfikowania (no chyba, że to twój prywatny VPN).
Ale to nie jest funkcja UDP tylko konkretna aplikacja dodaje sobie sama numer sekwencyjny

@kwitnaca-wisnia: Tak, i tak właśnie zostało napisane:
"UDP jest prostszy i tego wszystkiego musi "pilnować" sama aplikacja"
Chciałeś błysnąć wiedzą, ale nie do końca wyszło.
w UDP pakiety nie mają numerów sekwencyjnych także nie ma czego pilnować

@kwitnaca-wisnia: Kolego, wiesz, że dzwonią, ale nie wiesz, w którym kościele.

Jak pakiety UDP dojdą w złej kolejności, jest utrata danych - system ani aplikacja nie są w stanie tego skorygować.
Otóż aplikacja może operować własnym protokołem na warstwie UDP, i owszem, może sobie w tym protokole nadawać numery i korygować, a także wysyłać potwierdzenia. Wszystko po UDP. Pisałem
Ale to nie jest funkcja UDP tylko konkretna aplikacja dodaje sobie sama numer sekwencyjny z którego później korzysta. Rozmawiamy tutaj o protokole UDP, nie o prywatnych rozszerzeniach jakiejś tam aplikacji.


@kwitnaca-wisnia: ok ale Ty stwierdziłeś że pakiety UDP w złej kolejności to zawsze stracisz dane i apka ani system tego nie skorygują co jest nie prawdą bo wystarczy że aplikacja polu danych w pakiecie UDP nadaje swoje numery sekwencyjne i nie
Dobra chłopaki, fajnie że znacie się na UDP ale to nas nie doprowadza do rozwiązania problemu :P Nie chcę być niemiły ale za chwilę rozmowa nam ucieknie na jakieś niezwiązane niuanse ( ͡° ͜ʖ ͡°)

@zakowskijan72: Używam FreeNAS-11.3-U2.1 i mam cały panel konfiguracyjny do interfejsu sieciowego. igb0 (aktywny port) ma pole do wprowadzania MTU ale odrzuca mi wszystko poniżej 1492 właśnie. Przy czym tu jest jeszcze kolejna