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
  • Odpowiedz
@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?
  • Odpowiedz
@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.
  • Odpowiedz
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.
  • Odpowiedz
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
  • Odpowiedz
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
  • Odpowiedz
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ść
  • Odpowiedz
@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ą
  • Odpowiedz
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.
  • Odpowiedz
@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).
  • Odpowiedz
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.
  • Odpowiedz
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 takie protokoły, więc wiem
  • Odpowiedz
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
  • Odpowiedz
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
  • Odpowiedz