Hi,
kennt jemand eine Möglichkeit, ein "Application Gateway" für CVS zu bauen und würde die mir mitteilen? Grund: Clients -- FireWall -- Internet (CVS) Clients dürfen nur über einen Proxy ins Internet.
Über CONNECT:// zu tunneln soll wohl gehen, gefällt mir aber nicht, da der Web-Proxy das nur für Port 443 zulassen soll. SOCKS will ich auch nicht.
Danke,
Frank
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 05 February 2002 19:45, Frank Becker wrote:
Hi,
kennt jemand eine Möglichkeit, ein "Application Gateway" für CVS zu bauen und würde die mir mitteilen? Grund: Clients -- FireWall -- Internet (CVS) Clients dürfen nur über einen Proxy ins Internet.
Über CONNECT:// zu tunneln soll wohl gehen, gefällt mir aber nicht, da der Web-Proxy das nur für Port 443 zulassen soll. SOCKS will ich auch nicht.
Ist es eine Linux-Firewall? Wenn ja, dann richte eine Masquerading-Regel fuer Port 2401 (CVS-PServer, sehr unsicheres Protokoll!) und/oder 22 (ssh, ja man kann CVS via ssh tunneln) auf:
iptables -A POSTROUTING --dport 22 -o ppp0 -j MASQUERADE
Konrad
- -- Take a cookie! -- Oracle to Neo -- or was it my browser?
Konrad Rosenbaum (konrad.rosenbaum@t-online.de) schrieb auf LUG-DD am Die, 05 Feb, 2002; 21:04 +0100:
On Tuesday 05 February 2002 19:45, Frank Becker wrote:
Hi,
kennt jemand eine Möglichkeit, ein "Application Gateway" für CVS zu bauen und würde die mir mitteilen?
Ist es eine Linux-Firewall? Wenn ja, dann richte eine Masquerading-Regel fuer
Nein, leider nicht. Generelles NAT geht nicht.
Port 2401 (CVS-PServer, sehr unsicheres Protokoll!) und/oder 22 (ssh, ja man kann CVS via ssh tunneln) auf:
SSH ist keine Option. Brauche ich für Port-forwarding nicht einen account auf dem Zielsystem?
Danke,
Frank
On Tue Feb 05, 2002 at 23:42:29 +0100, Frank Becker wrote:
Konrad Rosenbaum (konrad.rosenbaum@t-online.de) schrieb auf LUG-DD am Die, 05 Feb, 2002; 21:04 +0100:
Port 2401 (CVS-PServer, sehr unsicheres Protokoll!) und/oder 22 (ssh, ja man kann CVS via ssh tunneln) auf:
SSH ist keine Option. Brauche ich für Port-forwarding nicht einen account auf dem Zielsystem?
Ja, sicherlich. Wenn das ganze per pserver liefe, braeuchten die Leute auch einen (CVS-)Account. So macht man ihnen einen SSH-Account ohne Shell und die Sache laeuft ueber SSH.
Adam
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 05 February 2002 23:42, Frank Becker wrote:
Konrad Rosenbaum (konrad.rosenbaum@t-online.de) schrieb auf LUG-DD am Die, 05 Feb, 2002; 21:04 +0100:
On Tuesday 05 February 2002 19:45, Frank Becker wrote:
kennt jemand eine Möglichkeit, ein "Application Gateway" für CVS zu bauen und würde die mir mitteilen?
Ist es eine Linux-Firewall? Wenn ja, dann richte eine Masquerading-Regel fuer
Nein, leider nicht. Generelles NAT geht nicht.
Dann hast Du keine Chance. CVS ist zu komplex, um es ueber einen Web-Proxy zu tunneln. (Abgesehen von _richtig_ boesartigen Tricks mit PPP ueber HTTP.)
Port 2401 (CVS-PServer, sehr unsicheres Protokoll!) und/oder 22 (ssh, ja man kann CVS via ssh tunneln) auf:
SSH ist keine Option. Brauche ich für Port-forwarding nicht einen account auf dem Zielsystem?
Account ja, Port-Forwarding nein. CVS kann ueber eine remote Shell sprechen. Eigentlich wurde es fuer die rsh entworfen, aber ssh versteht die gleiche Syntax, es ruft auf der anderen Seite einfach "cvs server" auf und tunnelt den Datenverkehr durch die "Terminal-Connection". Auf meinem Rechner zu Hause habe ich mir dazu einfach eine kleine chroot-Falle gebaut, in der man nur cvs aufrufen kann (funktioniert bei SourceForge/BerliOS/... aehnlich).
http://bogotron.rosenbaum.myip.org/cgi-bin/cvsweb.cgi/help/others/
Konrad
- -- Men of peace usually are [brave]. -- Spock, "The Savage Curtain", stardate 5906.5
Ist es eine Linux-Firewall? Wenn ja, dann richte eine Masquerading-Regel fuer Port 2401 (CVS-PServer, sehr unsicheres Protokoll!) und/oder 22 (ssh, ja man kann CVS via ssh tunneln) auf:
iptables -A POSTROUTING --dport 22 -o ppp0 -j MASQUERADE
Da hake ich mich doch gleich mal so ein:
wenn ich das richtig sehe routest du alles was an den Port 22 (und nich im Netzwerk ist) angesprochen wird direkt zum ppp0-Interface weiter? Meine Kenntnisse zu iptables sind _sehr_ dürftig, deswegen die Frage. Kann man denn dann auch alles vom Port 80 und so weiterleiten?? Könnte ich dann den ollen Squid weghauen? Jener stellt nähmlich bis jetzt eine Internet-Verbindung bereit.
Konrad
Bye, Sebastian
On Wed, Feb 06, 2002 at 01:22:26PM +0100, Sebastian Roth wrote:
Ist es eine Linux-Firewall? Wenn ja, dann richte eine Masquerading-Regel fuer Port 2401 (CVS-PServer, sehr unsicheres Protokoll!) und/oder 22 (ssh, ja man kann CVS via ssh tunneln) auf:
iptables -A POSTROUTING --dport 22 -o ppp0 -j MASQUERADE
wenn ich das richtig sehe routest du alles was an den Port 22 (und nich im Netzwerk ist) angesprochen wird direkt zum ppp0-Interface weiter? Meine Kenntnisse zu iptables sind _sehr_ dürftig, deswegen die Frage.
iptables hat erstmal nix mit Routing zu tun. Es sagt hier nur, daß *nach* der Routing-Entscheidung alles, was "out" durch ppp0 geht und als Ziel Port 22 hat (müßte hier nicht noch tcp mit rein?) dann masqueradet wird.
Kann man denn dann auch alles vom Port 80 und so weiterleiten?? Könnte ich dann den ollen Squid weghauen? Jener stellt nähmlich bis jetzt eine Internet-Verbindung bereit.
??? Wieso den squid weg, was hat das damit zu tun?
Heiko
Am Mittwoch, 6. Februar 2002 16:42 schrieb Heiko Schlittermann:
iptables hat erstmal nix mit Routing zu tun. Es sagt hier nur, daß *nach* der Routing-Entscheidung alles, was "out" durch ppp0 geht und als Ziel Port 22 hat (müßte hier nicht noch tcp mit rein?) dann masqueradet wird.
Das kapier ich erstmal!
Kann man denn dann auch alles vom Port 80 und so weiterleiten?? Könnte ich dann den ollen Squid weghauen? Jener stellt nähmlich bis jetzt eine Internet-Verbindung bereit.
??? Wieso den squid weg, was hat das damit zu tun?
Ok, hatte meine Situation zu wenig erklärt. Es ist folgendes: In einem Netzwerk steht ein Linux-Server. Der erledigt: - EMail-Dienste - Internetanbindung per DSL und Squid - Dateifreigabe Es ist ein heterogenes Netz -> Windows2000 Rechner + Laptops wollen diese Dienste nutzen. Bis auf die Sache Webanbindung funktioniert das auch, ABER wenn $Benutzer auf eine bestimmte Webseite (wegen Firmenkram) geht, soll(te) dort ein Java-Applet geladen werden. Das funktioniert bis jetzt allerdingens nur mit direkter Verbindung ins Internet, also per seperater ISDN-Leitung. Meine Vermutung: Squid verhaut irgendwie die Anfragen des Java-Applets ans Internet. Mit einem "direkten" Routing oder wie das heisst, sollte es ja korrekt funktionieren. Der Internet Explorer (d.h. Windows) bietet ja an, einen direkten Gateway einzurichten. Und deswegen hatte ich mich da reingehangen und die Frage dazu gestellt.
Heiko
Bye, Sebastian
On Wed, Feb 06, 2002 at 06:34:44PM +0100, Sebastian Roth wrote:
Meine Vermutung: Squid verhaut irgendwie die Anfragen des Java-Applets ans Internet.
squid ist ein HTTP-Proxy. Wenn das Java-Applet eine Verbindung nach außen aufbauen will und dafür nicht HTTP verwendet, wird das über den quid nicht klappen. Also stellt man entweder das Java-Applet auf HTTP um oder bohrt Löcher in den Gateway-Rechner. Wahrscheinlich kommuniziert das Applet nur mit einer festen Gegenstelle (ip/port). Dann könnte man genau für dieses Ziel NAT machen.
Mit einem "direkten" Routing oder wie das heisst, sollte es ja korrekt funktionieren. Der Internet Explorer (d.h. Windows) bietet ja an, einen direkten Gateway einzurichten.
Der Internet Explorer richtet eine Gateway ein? Ich nix kapieren.
Reinhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 06 February 2002 19:32, Reinhard Foerster wrote:
On Wed, Feb 06, 2002 at 06:34:44PM +0100, Sebastian Roth wrote:
Mit einem "direkten" Routing oder wie das heisst, sollte es ja korrekt funktionieren. Der Internet Explorer (d.h. Windows) bietet ja an, einen direkten Gateway einzurichten.
Der Internet Explorer richtet eine Gateway ein?
Windows == vermanschtes System.
Ich nix kapieren.
<SCNR> Wissen wir schon. </SCNR>
Aber im Ernst: Systemsteuerung -> Netzwerk -> Protokoll: TCP/IP -> Eigenschaften -> Gateway
Konrad
- -- BOFH excuse #86:
Runt packets
Am Mittwoch, 6. Februar 2002 19:32 schrieb Reinhard Foerster:
On Wed, Feb 06, 2002 at 06:34:44PM +0100, Sebastian Roth wrote:
Meine Vermutung: Squid verhaut irgendwie die Anfragen des Java-Applets ans Internet.
squid ist ein HTTP-Proxy. Wenn das Java-Applet eine Verbindung nach außen aufbauen will und dafür nicht HTTP verwendet, wird das über den quid nicht klappen. Also stellt man entweder das Java-Applet auf HTTP um oder bohrt Löcher in den Gateway-Rechner.
Das Applet kann ich nicht umstellen. Es wird ja erst gar nicht geladen über Squid, d.h. es kann nicht mit der Gegenstelle kommunizieren.
Wahrscheinlich kommuniziert das Applet nur mit einer festen Gegenstelle (ip/port). Dann könnte man genau für dieses Ziel NAT machen.
Wie geht das?
Würde denn folgendes klappen?: - squid weg - routing tabelle lassen (die funktioniert) - Linux in den Windows-Rechnern als Gateway eintragen - Linux routet (oder masqueradet oder was auch immer) alle Anfragen (die nicht im internen Netz schon zu finden sind) einfach auf ppp0 und damit ins Netz Also: Win2000 -> Anfrage an z.B. heise.de -> Gateway: lserver -> Internet Win2000 -> Anfrage an z.B. PC von Sekräterin -> Gateway: lserver -> Netzwerk
Die Routing-Tabelle sollte ja schon reichen.
Was meint ihr?
Reinhard
Bye, Sebastian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 07 February 2002 13:29, Sebastian Roth wrote:
Würde denn folgendes klappen?:
- squid weg
- routing tabelle lassen (die funktioniert)
- Linux in den Windows-Rechnern als Gateway eintragen
- Linux routet (oder masqueradet oder was auch immer) alle Anfragen (die
nicht im internen Netz schon zu finden sind) einfach auf ppp0 und damit ins Netz Also: Win2000 -> Anfrage an z.B. heise.de -> Gateway: lserver -> Internet Win2000 -> Anfrage an z.B. PC von Sekräterin -> Gateway: lserver -> Netzwerk
Die Routing-Tabelle sollte ja schon reichen.
Ich denke mal das Netz sieht etwa so aus:
[Hub/Switch] | | | | '------>[Rechner 1] | | | '-------->[Rechner 2] | | '---------->[Rechner 3] | '------------>[Rechner 4] | '------------>[lserver]->[ppp0]===>Internet
Wenn Rechner 1 mit Rechner 3 reden will bleibt das ja sowieso im selben Netzwerksegment (sagen wir mal 192.168.0.*). Dann ist lserver als Gateway eingetragen und alles was nach Internet will kommt demnach dort vorbei. Um den lokalen Kram braucht er sich gar nicht zu kuemmern (ausser dass er auch dort reden koennen muss, aber er braucht da nicht zu routen).
Das lokale Netz ist also kein Problem, fuer das externe Netz musst Du ueberall lserver als GW eintragen und auf lserver das machen:
echo 1 >/proc/sys/net/ipv4/ip_forward echo 1 >/proc/sys/net/ipv4/ip_dynaddr
iptables -A nat -o ppp0 -j MASQUERADE
und noch nach aussen etwas abdichten (Beispiele wurden glaub' ich schonmal gepostet).
Konrad
- -- BOFH excuse #66:
bit bucket overflow
Am Donnerstag, 7. Februar 2002 20:09 schrieb Konrad Rosenbaum:
Ich denke mal das Netz sieht etwa so aus:
[Hub/Switch]
| | | | '------>[Rechner 1] | | | | | | '-------->[Rechner 2] | | | | '---------->[Rechner 3] | | '------------>[Rechner 4]
'------------>[lserver]->[ppp0]===>Internet
Jepp, so sieht das aus.
Wenn Rechner 1 mit Rechner 3 reden will bleibt das ja sowieso im selben Netzwerksegment (sagen wir mal 192.168.0.*). Dann ist lserver als Gateway eingetragen und alles was nach Internet will kommt demnach dort vorbei. Um den lokalen Kram braucht er sich gar nicht zu kuemmern (ausser dass er auch dort reden koennen muss, aber er braucht da nicht zu routen).
Aber wenn ich im Windows unter Netzwerkeigenschaften den Linux als Gateway eintrage, sollte doch alles bei ihm vorbeikommen, oder? Wie macht windows das? Leider hab ich hier @home kein Netzwerk. :-(
Das lokale Netz ist also kein Problem, fuer das externe Netz musst Du ueberall lserver als GW eintragen und auf lserver das machen:
echo 1 >/proc/sys/net/ipv4/ip_forward echo 1 >/proc/sys/net/ipv4/ip_dynaddr
iptables -A nat -o ppp0 -j MASQUERADE
Frage dazu: dieses ppp0 habe ich bei mir zu Hause z.B nicht! D.h. nur wenn ich online bin isses da. Ist das dann beim Lserver (hat dial on demand) anders?
und noch nach aussen etwas abdichten (Beispiele wurden glaub' ich schonmal gepostet).
werde ich mir mal in Ruhe raussuchen. :-)
Konrad
Bye und Danke erstmal, Sebastian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 08 February 2002 23:08, Sebastian Roth wrote:
Am Donnerstag, 7. Februar 2002 20:09 schrieb Konrad Rosenbaum:
Ich denke mal das Netz sieht etwa so aus:
[cut]
Jepp, so sieht das aus.
Wenn Rechner 1 mit Rechner 3 reden will bleibt das ja sowieso im selben Netzwerksegment (sagen wir mal 192.168.0.*). Dann ist lserver als Gateway eingetragen und alles was nach Internet will kommt demnach dort vorbei. Um den lokalen Kram braucht er sich gar nicht zu kuemmern (ausser dass er auch dort reden koennen muss, aber er braucht da nicht zu routen).
Aber wenn ich im Windows unter Netzwerkeigenschaften den Linux als Gateway eintrage, sollte doch alles bei ihm vorbeikommen, oder? Wie macht windows das? Leider hab ich hier @home kein Netzwerk. :-(
Angenommen Du hast das eingetragen: IP=192.168.0.55 Netmask=255.255.255.0 Gateway=192.168.0.3
Dann heisst das, alles was an 192.168.0.* geht wird direkt aufs Ethernet geschickt. alles, was woanders hinkommt wird an 192.168.0.3 geschickt, der nach der ersten Regel ja direkt ueber Ethernet erreichbar ist.
Das lokale Netz ist also kein Problem, fuer das externe Netz musst Du ueberall lserver als GW eintragen und auf lserver das machen:
echo 1 >/proc/sys/net/ipv4/ip_forward echo 1 >/proc/sys/net/ipv4/ip_dynaddr
iptables -A nat -o ppp0 -j MASQUERADE
Frage dazu: dieses ppp0 habe ich bei mir zu Hause z.B nicht! D.h. nur wenn ich online bin isses da. Ist das dann beim Lserver (hat dial on demand) anders?
Es sollte auf lserver immer da sein, nur meistens ist es eben inaktiv. Selbst wenn es nicht da ist, kannst Du ja schonmal die Regel aufstellen, die wird dann halt erst aktiv, wenn ppp0 da ist.
Achso, wenn Du via ISDN reingehst muss das ippp0 heissen.
Konrad
- -- BOFH excuse #303:
fractal radiation jamming the backbone
Am Samstag, 9. Februar 2002 13:47 schrieb Konrad Rosenbaum:
Aber wenn ich im Windows unter Netzwerkeigenschaften den Linux als Gateway eintrage, sollte doch alles bei ihm vorbeikommen, oder? Wie macht windows das? Leider hab ich hier @home kein Netzwerk. :-(
Angenommen Du hast das eingetragen: IP=192.168.0.55 Netmask=255.255.255.0 Gateway=192.168.0.3
Dann heisst das, alles was an 192.168.0.* geht wird direkt aufs Ethernet geschickt. alles, was woanders hinkommt wird an 192.168.0.3 geschickt, der nach der ersten Regel ja direkt ueber Ethernet erreichbar ist.
*versteh* Also senden die Clients erst gar nicht interne Sachen an den Linux?
Frage dazu: dieses ppp0 habe ich bei mir zu Hause z.B nicht! D.h. nur wenn ich online bin isses da. Ist das dann beim Lserver (hat dial on demand) anders?
Es sollte auf lserver immer da sein, nur meistens ist es eben inaktiv. Selbst wenn es nicht da ist, kannst Du ja schonmal die Regel aufstellen, die wird dann halt erst aktiv, wenn ppp0 da ist.
Ich hab mal bei mir hier den iptables-Befehl ausprobiert: lserver:~ # iptables -A nat -o ppp0 -j MASQUERADE iptables v1.2.5: Couldn't load target `MASQUERADE':/usr/local/lib/iptables/libipt_MASQUERADE.so: cannot open shared object file: No such file or directory
Try `iptables -h' or 'iptables --help' for more information. lserver:~ #
was heisst das? Wo bekomme ich diese Lib her oder hab ich beim Kompilieren was vergessen?
Achso, wenn Du via ISDN reingehst muss das ippp0 heissen.
nein, wir haben noch Analog :-) Also ppp0?
Hmm, im Moment hab ich mir so eine RoutingTabelle aufgestellt. Wird mir das Masquerading dann etwas davon abnehmen? Also jetzt sieht sie so aus: 192.168.97.0 192.168.97.1 255.255.255.0 eth0 und beim Server steht da noch ein Eintrag mit ppp0, kann ich jenen dann wegnehmen?
Konrad
Bye, Sebastian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 06 February 2002 16:42, Heiko Schlittermann wrote:
On Wed, Feb 06, 2002 at 01:22:26PM +0100, Sebastian Roth wrote:
Ist es eine Linux-Firewall? Wenn ja, dann richte eine Masquerading-Regel fuer Port 2401 (CVS-PServer, sehr unsicheres Protokoll!) und/oder 22 (ssh, ja man kann CVS via ssh tunneln) auf:
iptables -A POSTROUTING --dport 22 -o ppp0 -j MASQUERADE
wenn ich das richtig sehe routest du alles was an den Port 22 (und nich im Netzwerk ist) angesprochen wird direkt zum ppp0-Interface weiter? Meine Kenntnisse zu iptables sind _sehr_ dürftig, deswegen die Frage.
iptables hat erstmal nix mit Routing zu tun. Es sagt hier nur, daß *nach* der Routing-Entscheidung alles, was "out" durch ppp0 geht und als Ziel Port 22 hat (müßte hier nicht noch tcp mit rein?) dann masqueradet wird.
ja, ich MASQ'e alles. Das oben war eine Adhoc Loesung. Adhoc die fehlende Option: -p tcp
Kann man denn dann auch alles vom Port 80 und so weiterleiten?? Könnte ich dann den ollen Squid weghauen? Jener stellt nähmlich bis jetzt eine Internet-Verbindung bereit.
Ja, aber dann verlierst Du den Cache und damit bekommst Du mehr Traffic nach drausen.
Konrad
- -- Schshschshchsch. -- The Gorn, "Arena", stardate 3046.2
On Tue, Feb 05, 2002 at 07:45:15PM +0100, Frank Becker wrote:
Hi,
kennt jemand eine Möglichkeit, ein "Application Gateway" für CVS zu bauen und würde die mir mitteilen? Grund: Clients -- FireWall -- Internet (CVS) Clients dürfen nur über einen Proxy ins Internet.
Wenn der Client nur lesen soll kannst du ein Web-Frontend zu CVS nutzen.
thomas
Thomas Guettler (guettli@thomas-guettler.de) schrieb auf LUG-DD am Die, 05 Feb, 2002; 21:44 +0100:
On Tue, Feb 05, 2002 at 07:45:15PM +0100, Frank Becker wrote:
Hi,
kennt jemand eine Möglichkeit, ein "Application Gateway" für CVS zu
[...]
Wenn der Client nur lesen soll kannst du ein Web-Frontend zu CVS nutzen.
Oh, ich glaube die wollen auch mal was schreiben.
Danke für die Antwort,
Frank
lug-dd@mailman.schlittermann.de
-
Adam Lackorzynski -
Frank Becker -
Heiko Schlittermann -
konrad.rosenbaum＠t-online.de -
Reinhard Foerster -
Sebastian Roth -
Thomas Guettler