# [SOLVED]wlasny serwer proxy

## wodzik

mam dosc tego, ze w akademiku blokowane jest praktycznie wrzystko, oprocz http. nie dziala git,svn i pare innych rzeczy. zastanawiam sie czy majac dostep do serwera z publicznym ip, mozna zrobic cos w stylu proxy, na wszystkie uslugi internetowe. powinno to wygladac mniej wiecej tak, ze wszystkie polaczenia ode_mnie wychodza na porcie http do tego sertwera, a tam sa przekierowywane gdzie trzeba.

Arfrever: Ortografia

----------

## taopai

 *wodzik wrote:*   

> mam dosc tego, ze w akademiku blokowane jest praktycznie wrzystko, oprocz http. nie dziala git,svn i pare innych rzeczy. zastanawiam sie czy majac dostep do serwera z publicznym ip, mozna zrobic cos w stylu proxy, na wszystkie uslugi internetowe. powinno to wygladac mniej wiecej tak, ze wszystkie polaczenia ode_mnie wychodza na porcie http do tego sertwera, a tam sa przekierowywane gdzie trzeba.
> 
> Arfrever: Ortografia

 

Hmmm... SOCKS? http://en.wikipedia.org/wiki/SOCKS

Pozdrawiam,

Tao

----------

## wodzik

mogl bys cos jasniej. nie moge znalezc nigdzie jak sie tego uzywa. poza_tym na serwerze nie mam praw roota.

Arfrever: Ortografia

----------

## cast0r

bez praw roota to raczej nic nie zdzialasz w tej sprawie.

Sam kiedys, takie cos zrobilem ale przy uzyciu OpenVPN. OpenVPN dlatego ze latwo sie to stawia i konfiguruje oraz dlatego ze jesli dziala na porcie 443 to dla proxy HTTP wyglada jak zwykle polaczenie SSL , poza tym jesli postawisz jakis serwer na porcie 80 czy 443 to i tak proxy tego nie przepusci (poda dalej) jesli nie bedzie to protokol HTTP lub SSL.

Wiec w bardzo restryktywnych srodowiskach jedynym wyjsciem jest OpenVPN na 443. Tak skonfigurowany serwer umozliwi ci przekierowanie WSZYSTKICH polaczen przez twoj serwer. Inny plus tego to ze OpenVPN jest tez na Windows i OS X wiec umozliwi ci przekierowanie ruchu z kazdej platformy.

----------

## SlashBeast

Mozna przeca uzyc SSH, odpalic gdzies ssh na porcie 80 i tam, gdzie mamy tak poblokoway net wstukać:

```
ssh user@host-zdalny -p 80 -D 1234 -v -N
```

A w przeglądarce itp. wpisać jako proxy localhost, port proxy 1234 a typ proxy socsk5, można użyć do tego tsocks by zmusić wszystkie aplikacje do używania proxy, nawet jak one tego nie wspierają.

Opcjonalnie, można jeszcze dodać przełącznik -C, używa kompresji gzip mędzy nami a zdalnym hostem oszczędzając trafic.

----------

## wodzik

znalazlem takie cos:

```
Jeśli nie chcemy lub nie możemy wykorzystać programu "tsocks" możemy przekierować tylko jeden lub więcej portów w zestawionym tunelu SSH.

Podaję przykład:

autossh -CNfp 60022 -M 60023 \

    -L 81:localhost:80 \

    -L 1213:localhost:1213 \

    -L 4000:localhost:4000 \

    -L 4001:localhost:4001 \

    -L 4080:localhost:4080 \

    -D 8080 user@zdalny_host

Zgodnie z przykładem aby wyświetlić stronę WWW na zdalnym hoście to w przeglądarce wpisujemy adres lokalny tzn: http://localhost:81 zamiast http://zdalny_host:80
```

jednak chyba nie calkiem dziala. po wpisaniu: ssh wodzik@serwer -D 1234 -v -N  -L 81:localhost:80 i wpisaniu w adres przegladarki whatismyip.org:81 nie moze sie polaczyc. na konsoli wyrzuca:

```
debug1: Local connections to LOCALHOST:1234 forwarded to remote address socks:0

debug1: Local forwarding listening on 127.0.0.1 port 1234.

debug1: channel 0: new [port listener]

debug1: Local forwarding listening on ::1 port 1234.

debug1: channel 1: new [port listener]

debug1: Local connections to LOCALHOST:81 forwarded to remote address localhost:80

debug1: Local forwarding listening on 127.0.0.1 port 81.

debug1: channel 2: new [port listener]

debug1: Local forwarding listening on ::1 port 81.

debug1: channel 3: new [port listener]

debug1: Entering interactive session.

debug1: channel 0: free: port listener, nchannels 4

debug1: channel 1: free: port listener, nchannels 3

debug1: channel 2: free: port listener, nchannels 2

debug1: channel 3: free: port listener, nchannels 1

```

zaraz sprobuje z tsocks. 

opis wzialem  ze stronki: http://osunix.net/index.php?q=node/50

----------

## cast0r

 *SlashBeast wrote:*   

> Mozna przeca uzyc SSH, odpalic gdzies ssh na porcie 80 ....

 

wlasnie nie zawsze mozna  :Smile:  dlatego bylem zmuszony do tunelu  SSL wiec wybor padl na OpenVPN. Bo  tam gdzie jest http proxy wcale nie znaczy ze port 80 jest otwarty dla innych.  A na 443 proxy podawal dalej tylko SSL/HTTPS a SSH juz nie.

Ale to zalezy od restrykcji w danej sieci  co sie ostatecznie wybierze.

----------

## timor

 *cast0r wrote:*   

> ... wlasnie nie zawsze mozna  ...

 A ja byłbym bardzo ciekaw jak ustawić zdalny serwer ssh do tego aby tak działał, bo też kiedyś próbowałem i nie poszło, a czasem by się przydało....  :Wink: 

----------

## SlashBeast

A co w tym trudnego? Mi to zawsze dziala out-of-box, a używam takich tuneli kilka razy dziennie nawet.

----------

## timor

 *SlashBeast wrote:*   

> A co w tym trudnego? Mi to zawsze dziala out-of-box, a używam takich tuneli kilka razy dziennie nawet.

 A mi nie  :Wink:  Prawdopodobnie dlatego, że mam bardziej restrykcyjnie ustawionego demona ssh - dlatego chciałbym wiedzieć jak go ustawić poprawnie.

----------

## cast0r

 *timor wrote:*   

>  *cast0r wrote:*   ... wlasnie nie zawsze mozna  ... A ja byłbym bardzo ciekaw jak ustawić zdalny serwer ssh do tego aby tak działał, bo też kiedyś próbowałem i nie poszło, a czasem by się przydało.... 

 

nie rozumiesz mnie  :Smile: 

NIe chodzi o serwer ssh na 80, tylko o to ze nie mozesz sie do niego polaczyc przez ten port z owej sieci! Bo tam gdzie jest http proxy wcale nie znaczy ze port 80 jest otwarty dla innych na zewnatrz.

----------

## timor

 *cast0r wrote:*   

> nie rozumiesz mnie 
> 
> NIe chodzi o serwer ssh na 80, tylko o to ze nie mozesz sie do niego polaczyc przez ten port z owej sieci! Bo tam gdzie jest http proxy wcale nie znaczy ze port 80 jest otwarty dla innych na zewnatrz.

 Wiem jak to działa  :Razz: 

Http proxy może sprawdzać czy to co idzie przez port 80 rzeczywiście jest ruchem http, jak mu się nagłówki nie zgadzają to można to ciąć.

Ja miałem inny problem, że za cholerę nie działało mi socks proxy, czyli łączę się ze zdalnym serwerem przez ssh (ustawiam tunel), zmieniam właściwości w ff i dupa ;/ Nie działają mi strony. Byłbym wdzięczny za pomoc w zdiagnozowaniu tego. Mogę podesłać trochę z tego co ssh wypluwa.

----------

## cast0r

 *timor wrote:*   

> 
> 
> Ja miałem inny problem, że za cholerę nie działało mi socks proxy, czyli łączę się ze zdalnym serwerem przez ssh (ustawiam tunel), zmieniam właściwości w ff i dupa ;/ Nie działają mi strony. Byłbym wdzięczny za pomoc w zdiagnozowaniu tego. Mogę podesłać trochę z tego co ssh wypluwa.

 

opisz dokladniej co robisz i jak oraz z jakiej platformy sie laczysz z serwerem, logami rzucic tez nie zaszkodzi  :Smile: 

... bo: , jesli mozesz sie zalogowac na serwer poprzez ssh i robisz to tak jak wyzej napisal SlashBeast to nie ma prawa nie dzialac. no chyba ze serwer nie zezwala na tunelowanie(choc powinnien domyslnie), a w tym wypadku jesli to twoj serwer to do sshd_config odsylam.

----------

## timor

Wygląda to tak:

```
ja@moj_komp ~ $ ssh -D 1234 -v -N remote_host

OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007

debug1: Reading configuration data /home/ruser/.ssh/config

debug1: Applying options for remote_host

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to remote_host [xxx.xxx.xxx.xxx] port 22.

debug1: Connection established.

debug1: identity file /home/ruser/.ssh/id_rsa type 1

debug1: identity file /home/ruser/.ssh/id_dsa type 2

debug1: Remote protocol version 1.99, remote software version OpenSSH_4.0

debug1: match: OpenSSH_4.0 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.7

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'remote_host' is known and matches the RSA host key.

debug1: Found key in /home/ruser/.ssh/known_hosts:3

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,gssapi-with-mic,password

debug1: Next authentication method: publickey

debug1: Offering public key: /home/ruser/.ssh/id_rsa

debug1: Authentications that can continue: publickey,gssapi-with-mic,password

debug1: Offering public key: /home/ruser/.ssh/id_dsa

debug1: Server accepts key: pkalg ssh-dss blen 433

debug1: Authentication succeeded (publickey).

debug1: Local connections to LOCALHOST:1234 forwarded to remote address socks:0

debug1: Local forwarding listening on 127.0.0.1 port 1234.

debug1: channel 0: new [port listener]

socket: Address family not supported by protocol

debug1: Entering interactive session.

debug1: Connection to port 1234 forwarding to socks port 0 requested.

debug1: channel 1: new [dynamic-tcpip]

debug1: channel 1: free: dynamic-tcpip, nchannels 2

debug1: Connection to port 1234 forwarding to socks port 0 requested.

debug1: channel 1: new [dynamic-tcpip]

debug1: channel 1: free: dynamic-tcpip, nchannels 2

debug1: Connection to port 1234 forwarding to socks port 0 requested.

debug1: channel 1: new [dynamic-tcpip]

debug1: channel 1: free: dynamic-tcpip, nchannels 2

debug1: Connection to port 1234 forwarding to socks port 0 requested.

debug1: channel 1: new [dynamic-tcpip]

debug1: channel 1: free: dynamic-tcpip, nchannels 2

debug1: Connection to port 1234 forwarding to socks port 0 requested.

debug1: channel 1: new [dynamic-tcpip]

debug1: channel 1: free: dynamic-tcpip, nchannels 2

debug1: Connection to port 1234 forwarding to socks port 0 requested.

debug1: channel 1: new [dynamic-tcpip]

debug1: channel 1: free: dynamic-tcpip, nchannels 2

debug1: Connection to port 1234 forwarding to socks port 0 requested.

debug1: channel 1: new [dynamic-tcpip]

.... itd
```

Potem w zakładce proxy ff, ustawiam adres na 127.0.0.1 (lub wpisuję localhost) oraz port 1234.

remote_host to serwerek na starej fedorze (bodajże 4-ce) - nie bardzo jest możliwość żeby go zaktualizować. sshd_config z niego:

```
Port 22

Protocol 2,1

ListenAddress 0.0.0.0

SyslogFacility AUTHPRIV

PubkeyAuthentication yes

AuthorizedKeysFile   .ssh/authorized_keys

PasswordAuthentication yes

ChallengeResponseAuthentication no

GSSAPIAuthentication yes

GSSAPICleanupCredentials yes

UsePAM yes

AllowTcpForwarding yes

GatewayPorts yes

X11Forwarding yes

TCPKeepAlive yes

Subsystem   sftp   /usr/libexec/openssh/sftp-server
```

Byłbym wdzięczny za sugestie. Według mnie config ssh jest niezbyt bezpieczny ale to nie moja sprawa  :Wink: 

----------

## SlashBeast

powinno działać,  Daj w foxie manual proxy configuration wszystkie pola od proxy w stylu http, ssl, ftp itp. zostaw puste, wpisz tylko w SOCKS localhost i port jakiego używasz,  wybiesz SOCKS v5 i musi dzialać.

----------

## timor

HA! Rzeczywiście, wystarczy tylko socks ustawić i śmiga  :Wink: 

Dzięki stary!

----------

## wodzik

trochę odświeżę temat. znalazłem http://www.kadu.net/w/Subversion czyli dokładnie to o co mi chodzi. jak najmniejsza ilość kombinowania. prosto łatwo i przyjemnie. może poza tym, że svn dalej nie działa. nie wiem czy to ważne, ale przy połączeniu pokazuje mi takie cos:

```
BoLs ~ # ssh -i .ssh/id_rsa -gND 5432 wodzik@gdziestam.com

bind: Address already in use

```

zaraz popróbuje zrobić wg. tej wcześniejszej stronki, tylko musze znaleźć na jakim porcie śmiga ssh

-----------EDIT------------

ok juz działa. wina w konfiguracji. trzeba było dać linijkę: server = localhost. teraz mam mały problem, jak zmusić emerge do korzystania z tego. dałem aliasy alias git='tsocks git' i tak samo na svn, ale emerge chyba podaje pełna ścieżkę. sprobuje podmienić pliki svn i git na skrypty odpalające je przez tsocksa.

------EDIT2------------

wie może ktoś, jak przekazać w bashu parametry przekazane do skryptu, dalej? tj. wywołuje skrypt z parametrami clone adres, a on odpala gita z tymi parametrami? wiem jak to zrobić w c, ale nie wiem czy jest sens pisać na to program ;]

---------EDIT3-------------

żeby nie było, że nie szukałem. wydaje mi się, ze powinno to wyglądać jakoś w stylu: /usr/bin/tsocks git_old $@,  po przeniesieniu git do git_old, tyle  że nie pasuje mu składnia.

----------

## wodzik

trochę podbije temat. okazuje się, że mimo usilnych prób nie idzie zrobić takiego myku. git cały czas twierdzi, że składnia jest zła. prawdopodobnie sprawdza czy argv[0] sie zgadza, czyli czy nazwa programu jest dobra. żeby sie upewnić czy to nie wina basha napisałem już to nawet w c:

```
#include<stdlib.h>

#include<stdio.h>

#include <string.h>

int main(int argc, char * argv[])

{

   int i;

   char  cos[10000]="/usr/bin/git_old "; 

   for( i = 1; i < argc; i++)

   {

      strcat(cos,argv[i]);

      strcat(cos," ");

   }

   system((const char *)cos);

}
```

pomysły mi sie skończyły. może ktoś wie jak zmusić gita i svn bezboleśnie, żeby korzystały przez emerge z tsocks?

----------

## Arfrever

Możesz zmienić ESVN_FETCH_CMD i ESVN_UPDATE_CMD w subversion.eclass oraz EGIT_FETCH_CMD i EGIT_UPDATE_CMD w git.eclass.

----------

## wodzik

dokładnie. teraz by sie przydał jakiś skrypt na zautomatyzowanie tego. bo miło by było, żeby korzystał z tsocks tylko kiedy ja chce. ale na razie daje solved

----------

