Beantwortet: Squid Kaskade

D

DebianCore

Member
Tag,

kann mir jemand erklären,
wie ich eine Kaskade mit Squid realisiere?

Am besten wäre sowas wie:
VPN - SSH - squid - socks5.

OS:
Linux Mint 16 kde

Vllt. kann mir ja jemand helfen,
welche Befehle ich dafür brauche.
 
Sort by date Sort by votes
JackCarver;n5779 said:
ssh -N user@server1 -L 8010:server2:22 ssh -N user@127.0.0.1 -P 8010 -L 8011:127.0.0.1:3128
Click to expand...

Ich versuch das mal aufzuschlüsseln einfach nur für mein eigenes Verständnis.

ssh -N mein-Benutzername@PP-VPN-Server -L Port-8010-auf-VPN-Server : PP-SSH-Server : 22
Mit dem Befehl in der Konsole würde ich ja vom VPN Server auf Port 8010 einen Tunnel zum SSH Server auf Port 22 aufbauen ?

So und jetzt wirds kniffelig für mich als Laie aber ich versuch es mal.

ssh -N Terminal-Benutzer@127.0.0.1(=mein PC oder?) -p 8010(schon aufgebaute PC-VPN-SSH-Verbindung?) und ab -L wirds für mich unverständlich. Wenn ich über SSH zum Squid möchte der als Ausgang dienen soll müsste es meiner Denkweise gerade so aussehen:
-L 8011:Squid-IP:3128 oder lieg ich da gerade komplett falsch ? Erklär mal bitte beide Befehle im Detail ich glaube damit ist dem Threadersteller und mir schonmal ein bisschen geholfen ;)
 
Upvote 0 Downvote
Befehl Nr 1 stellt ne Verbindung her zum ssh Server1 und bindet den Port 22 (was letztlich wieder der ssh Dienst ist) von ssh Server2 an deinen PC mit Port 8010. Das heißt an Port 8010 deines PCs lauscht der ssh Server2.
Daher ist die 127.0.0.1 im zweiten Befehl bei user@127.0.0.1 dein PC, da musst du allerdings noch den Port 8010 angeben, da ssh standardmässig an Port 22 lauscht.

Mit dem zweiten Befehl verbindest du dich also zu ssh Server2 und bindest nun den Squid Port 3128 von demselben Server, also auch von ssh Server2 an deinen PC.
Die zweiten 127.0.0.1 sind also der ssh Server2 auf dem auch ein Squid Server läuft dessen Port du an deinen PC bindest.

Du hast also folgende Kette:

Dein PC -> ssh-Server1 -> ssh-Server2 -> Squid -> Internet

Und da ssh-Server2 und der Squid dieselbe Maschine sind ist die komplette Kette ssh verschlüssselt. Zugriff auf die Kette erhältst du indem du zb im Firefox als Proxy die 127.0.0.1 mit Port 8011 einträgst.
 
Upvote 0 Downvote
JackCarver;n5948 said:
Befehl Nr 1 stellt ne Verbindung her zum ssh Server1 und bindet den Port 22 (was letztlich wieder der ssh Dienst ist) von ssh Server2 an deinen PC mit Port 8010. Das heißt an Port 8010 deines PCs lauscht der ssh Server2.
Daher ist die 127.0.0.1 im zweiten Befehl bei user@127.0.0.1 dein PC, da musst du allerdings noch den Port 8010 angeben, da ssh standardmässig an Port 22 lauscht.

Mit dem zweiten Befehl verbindest du dich also zu ssh Server2 und bindest nun den Squid Port 3128 von demselben Server, also auch von ssh Server2 an deinen PC.
Die zweiten 127.0.0.1 sind also der ssh Server2 auf dem auch ein Squid Server läuft dessen Port du an deinen PC bindest.

Du hast also folgende Kette:

Dein PC -> ssh-Server1 -> ssh-Server2 -> Squid -> Internet

Und da ssh-Server2 und der Squid dieselbe Maschine sind ist die komplette Kette ssh verschlüssselt. Zugriff auf die Kette erhältst du indem du zb im Firefox als Proxy die 127.0.0.1 mit Port 8011 einträgst.
Click to expand...

Es ist für mich unlogisch oder ich bin einfach zu blöd es zu raffen.


JackCarver;n5779 said:
ssh -N user@server1 -L 8010:server2:22
ssh -N user@127.0.0.1 -p 8010 -L 8011:127.0.0.1:3128
Click to expand...
Das würde heissen: ssh -N user@server1 (Verbindung zu Server1 hergestellt) -L 8010:server2:22 (Benutze Port 8010 auf meinem Heim PC und verbinde ihn mit Port 22 von Server2)

Von welchem Port aus bin ich denn jetzt auf !SSH-Server1! verbunden und vor allem wann schalte ich Server1 mit Server2 in Reihe ?

ssh -N user@127.0.0.1 -p 8010 (Heim-PC benutze port 8010 für Verbindungen nach draußen, demnach mit Server 2 verbunden) -L8011:127.0.0.1(in diesem Fall Server2):3128 (Server 2 binde deinen eigenen Port 8011 an den Squid Port 3128 der ebenfalls auf dir selbst läuft)

Demnach bin ich gerade nicht bei dieser Verbindung:
Dein PC -> ssh-Server1 -> ssh-Server2 -> Squid -> Internet

Sondern eher bei dieser:
Dein PC -> SSH-Server 1 (ist zwar zu Server 1 verbunden aber von Server aus ist kein Portforwarding gemacht worden also läuft die Verbindung ins leere ?)
Dein PC -> SSH-Server2 -> Squid

So versteh ich es wenn ich die Befehle Schritt für Schritt durchgehe und mir deine Erklärung durchlese. Ich tippe aber mal eher auf Denkfehler von mir, dass wäre nichts Neues ;)
 
Upvote 0 Downvote
Von welchem Port aus du verbunden bist ist komplett unerheblich und auch rein zufällig. Das ist einfach n Port, den dein Rechner beim Öffnen des Netzwerksocket als Quellport geöffnet hat und hierfür nicht wichtig.

Zu den Befehlen nochmal:

(1) ssh -N user@IP-Server1 -L 8010:IP-Server2:22
Click to expand...

Du startest ne ssh Verbindung zu Server1 (das macht der erste Teil des Befehls) und teilst Server1 gleichzeitig mit, dass er den Port 22 von Server2 an deinen lokalen Port 8010 binden soll (der zweite Teil des Befehls).

Du hast also ne aktive ssh Verbindung zu Server1 und zeitgleich lauscht an deinem lokalen Port 8010 der Port 22 von Server2 was letztendlich den ssh Server auf Server2 darstellt.

(2) ssh -N user@127.0.0.1 -p 8010 -L 8011:127.0.0.1:3128
Click to expand...

Der erste Teil des Befehls stellt nun wieder eine Verbindung zu ssh Server2 her. Das MUSS aber über Server1 laufen, da nur dieser die Verbindung zwischen Port 8010 auf deiner Maschine und Port 22 von ssh Server2 aufrecht erhält.
Nur weil ssh Server2 an deinem lokalen Port 8010 lauscht erreichst du Server2 über IP 127.0.0.1, das würde sonst ja nicht gehen.

Du hast also nun deine Reihenschaltung der beiden ssh Server erreicht und könntest diese mit bel. weiteren genauso fortführen. Nun wollen wir allerdings ins Internet und hier kommt der Squid ins Spiel.

Der zweite Teil des Befehls bindet nun den Squid Port von Server2 an deinen lokalen Port 8011. Da wir bereits über den ersten Teil des Befehls auf Server2 sind MUSS hier wieder die 127.0.0.1 kommen.

Und damit hast du eine verschlüsselte ssh Kette erreicht bis zum Squid, der auf derselben Maschine läuft wie der ssh Server von Server2. Und das lässt sich wie gesagt beliebig erweitern und ist auch ne saubere Sache im Gegensatz zum Proxifier chaining Mist wo keine Sau weiß was der überhaupt verkettet...
 
Upvote 0 Downvote
JackCarver;n5978 said:
Von welchem Port aus du verbunden bist ist komplett unerheblich und auch rein zufällig. Das ist einfach n Port, den dein Rechner beim Öffnen des Netzwerksocket als Quellport geöffnet hat und hierfür nicht wichtig.

Du startest ne ssh Verbindung zu Server1 (das macht der erste Teil des Befehls) und teilst Server1 gleichzeitig mit, dass er den Port 22 von Server2 an deinen lokalen Port 8010 binden soll (der zweite Teil des Befehls).

Du hast also ne aktive ssh Verbindung zu Server1 und zeitgleich lauscht an deinem lokalen Port 8010 der Port 22 von Server2 was letztendlich den ssh Server auf Server2 darstellt.

Der erste Teil des Befehls stellt nun wieder eine Verbindung zu ssh Server2 her. Das MUSS aber über Server1 laufen, da nur dieser die Verbindung zwischen Port 8010 auf deiner Maschine und Port 22 von ssh Server2 aufrecht erhält.
Click to expand...

Danke ! Ich glaube das waren genau die Antworten die ich gesucht habe :)
 
Upvote 0 Downvote
Nochmal ne dumme Frage. Ich verbinde mich über de NM mit nem oVPN Server z.B. Amsterdam und mache dann in 2 verschiedenen Terminals ne SSH Sitzung auf zu nem Socks/Squid z.B. Moskau läuft das dann erst übers VPN und dann per SSH zum Squid/Proxy oder läuft das dann am VPN vorbei ? Hab auf der Homepage gelesen das ich nur die interne IP benutzen muss wenn ich auf Amsterdam VPN verbunden bin und Amsterdam auch als Squid/Proxy verwenden will.
 
Upvote 0 Downvote
Läuft immer erst über VPN, da das Routing das so erzwingt. Danach erst per ssh zum Socks/Squid. Wenn du auf Amsterdam per VPN verbunden bist und du möchtest dann auf dem Amsterdam den Squid nutzen, dann nimm wie auf der Homepage die interne IP.

Nimmst du die externe vom VPN Server, dann läuft der Traffic am VPN vorbei, da Verbindungen von deinem Rechner zur externer IP des VPN Servers am Tunnel vorbei gehen müssen, sonst käme keine Verbindung zustande.
 
Upvote 0 Downvote
SSH-Kaskade

JackCarver said:
ssh -N user@server1 -L 8010:server2:22
ssh -N user@127.0.0.1 -p 8010 -L 8011:127.0.0.1:3128
Click to expand...

Schade, das Jack nicht länger aktiv ist, aber vielleicht kann mir ein Anderer hier weiterhelfen.

Da die Passworteingabe nervig ist, wird das Passwort aus der Passwortdatei ausgelesen.
Der erste Server sei Paris, Nr. zwei Erfurt.

Terminal1:
Code: 
sshpass -f ~/.ssh/passwordfile ssh -4 -N user@paris.perfect-privacy.com -L 5080:erfurt.perfect-privacy.com:22
Terminal2:
Code: 
sshpass -f ~/.ssh/passwordfile ssh -4 -N user@127.0.0.1 -p 5080 -L 5081:127.0.0.1:3128

watch -n 1 lsof -i ergibt:
Code: 
ssh       93034            user    3u  IPv4 503295      0t0  TCP comp:37164->dedi-fr-483415.op-net.com:ssh (ESTABLISHED)
ssh       93034            user    4u  IPv4 503297      0t0  TCP localhost:5080 (LISTEN)
ssh       93034            user    5u  IPv4 503373      0t0  TCP localhost:5080->localhost:44584 (ESTABLISHED)
ssh       93115            user    3u  IPv4 506025      0t0  TCP localhost:44584->localhost:5080 (ESTABLISHED)
ssh       93115            user    4u  IPv4 506041      0t0  TCP localhost:5081 (LISTEN)
Hier wundert mich, dass die Erfurt-Verbindung nicht angezeigt wird.

Nun prüfe ich die erste Verbindung mit
Code: 
curl -4 --proxy http://127.0.0.1:5080 https://checkip.perfect-privacy.com/csv
und erhalte
Code: 
curl: (56) Proxy CONNECT aborted
Hier wundert mich, dass die Paris-Verbindung nicht angezeigt wird.

sowie die zweite Verbundung mit
Code: 
curl -4 --proxy http://127.0.0.1:5081 https://checkip.perfect-privacy.com/csv
und erhalte
Code: 
IP,DNS,VPN,TOR,COUNTRY,CITY
217.114.218.18,erfurt1.perfect-privacy.com,true,false,Germany,Erfurt

Ich vermute mal, dass ist OK so.
Vielleicht weiß jemand, wie sich Server1+2 mit einer bestimmten Anwndung prüfen lassen, so das beide angezeigt werden.
Oder aber erklären, warum die Anzeigen so sind, wie sie sind.
 
Upvote 0 Downvote
You must log in or register to reply here.
Back
Top