F**K TPSA

[Grzegorz Sójka]

Maciej Pijanka wrote:
> 05-12-05, marcin steć <marcinek w nea.pl> napisał(a):
> 
>>Grzegorz Sójka wrote:
>>
>>
>>>[...].
>>>
>>>Życze dobrzych transferów.
>>>
>>>
>>
>>Hmmm, pomysł fajny.
>>Ale z tego co wiem kompresja ppp dotyczy tylko jakiegoś uproszczenia
>>nagłówka IP. Korzystając z tego, że połączenie jest point-to-point
>>wyrzuca się zbędne w tym przypadku pola z nagłwka IP. nie pamiętam
>>które, ale jest to parę bajtów na każdym pakiecie. Opisane w RFC bodajże
>>1962.
>>Z innego źródła (podręczy guru od sieci) dowiedziałem się, że urywa się
>>zaledwie jeden bajt na datagramie, bo kompresja tak jak ją
>>przedstawiałem to był w CSLIPie i jest na dzieńdobry w PPP.
> 
> 
> a
> The compression proposed in the Van Jacobson protocol is similar in
> spirit to the Thinwire-II protocol. However, this protocol compresses
> more effectively (the average compressed header is 3 bytes compared to
> 13 in Thinwire-II) and is both efficient and simple to implement. Van
> Jacobson compression is specific to TCP/IP datagrams.
> 
> a przy kompresji ppp over ssh na samej kompresji ssh (zlib) mozna conieco zyskac
> choc pewnie uzycie protokolu ktory nie marnuje naglowka TCP na cos co
> jest malo potrzebne (port itd) i idzie bezposrednio przy pomocy
> jakiegos GRE moglby byc efektywniejszy..

Co do kompresji ppp to nie polega ona tylko na obcinaniu niepotrzebnych
rzeczy z nagłówka. Bo jeśli by tak bylo to jak wytłumaczycie opcje:
-deflate oraz -bsdcomp do pppd? Poza tym nie dało by się osiągnąć
zanotowanej przezemnie przepustowości 1050Kbps na łączu o fizycznej
wydajności 256Kbps. Jest to różnicz żędu 400%! Owszem wynik jest
chwilowy ale przez dłuższy czas utrzymywał się transfer powyżej 500Kbps
co jest i tak 2 razy szybciej niż fizyczna wydajnośc łącza.

Przy okazji mam kolejne pytanie. Sytuacja wygląda tak, że mamy sieć
wewnętrzną (192.168.0.0/24) i geteway z maskaradą na PLD-AC. U mnie na
razie wygląda to tak, ze na geteway jest regułka która trafic wychodzący
na port 80 przekierowuje na transparent proxy. Jedmakże nie widać
powodu, zeby tylko http miało iśc przez tunel. Dlatego zastanawiam się
jak to zrobić, żeby trafic wychodzący z sieci wewnętrznej nie był
maskowany na geteway u mnie w domu ale w całości routowany przez tunel a
następnie maskowany na kompie u mnie w pracy i dopiero wysyłany w świat.
Z oczywistych względów ustawienie default gw na drugi koniec tunelu jest
złym pomysłem. To oznacza, ze potrzebny jest wpis mówiący, ze jeśli mamy
do sforwardowania pakiet pochodzący z 192.168.0.0/24 to zamiast przez dw
routujemy go przez drugi koniec tunelu. Ja niesttey nie znam się na
iptables wystarczająco dobrze. Jeśli więc ktoś wie jak to zrobic to
proszę o info.

Pozdrówka
Grzesiek