Guten Tag Udo Mueller, Am Mittwoch, 23. M�rz 2005 um 17:58 schrieb Udo Mueller:
> Hallo Stefan, > * Stefan Schilling schrieb [23-03-05 13:54]: >> Am Mittwoch, 23. M�rz 2005 um 01:06 schrieb Udo Mueller: >> > * Stefan Schilling schrieb [22-03-05 11:07]: >> > Ich rede ja auch nicht von der Uni, sondern von deinem Server. Der >> > soll wissen, welches Netz, bzw. hier nur welche IP hinter dem VPN >> > existiert. >> >> kennt er. Er ist der GW f�r alle Rechner in meinem LAN, deswegen >> gibt?s immer auch eine Route �ber eth0 ins 192.168.100.0 Netz, wobei >> eth0 die Adresse 192.168.100.1 hat. >> In die andere Richtung hat er einen Routingeintrag > Ich rede von der anderen Richtung. Nicht dein LAN ist entscheidend, > sondern die echte IP des Uni-Rechners. >> 172.16.1.0 172.16.1.2 255.255.255.0 UG 0 0 0 tun0 >> >> und der m�sste ihm ja sagen, dass er alle Rechner/Adressen, die mit >> 172.16.1.x beginnen, �ber tun0 erreicht, wobei tun0 ja die Adresse >> 172.16.1.1 hat: > tut er auch. Aber was ist mit der IP 141.13.x.y? kennt er einerseits �ber den Tunnel (im Log steht jedenfalls, dass er dem reinkommenden Clienten eine IP zuweisst (ich habs jetzt mal manuell auf 172.16.1.2 festgelegt und intern muss der VPN das ja auch wissen, nicht?)), andererseits nat�rlich nur �ber den normalen GW des Providers. >> >> >> - smbclient -L 192.168.100.2 >> >> >> >> > Dito. >> >> >> >> dann d�rfte es aber nach Abschaltung der Firewall auch nicht klappen. >> >> Es sei denn, die pings k�men tats�chlich von ausserhalb des Tunnels. >> >> Aber das d�rfte ja eigentlich nun gleich gar nicht funktionieren >> >> (s.o.) >> >> > Doch, kann sehr wohl klappen, weil dein Server jetzt die >> > Antwortpakete vom XP-Client �ber das �ffentliche Internet zur�ck an >> > den Client1 sendet. >> >> aber m�sste er nicht als Absenderpaket die IP 172.16.1.6 > Nein. Er nimmt die 141.13.x.y. ich habe grade mal ein paar Tests (ping an verschiedene Adressen im Server, mit + ohne laufender Firewall) mit tcpdumb laufen lassen. Hinweis vorweg: ich sitze inzwischen zu Hause an einem XP und bin mittels openvpn und einem normalen ssh-Zugang mit meinem Server verbunden; Adressen: Client1 = 172.16.1.2 (=tun0 auf XP), Server = eth0: 192.168.100.1, tun0: 172.16.1.1 Ergebnis: --zun�chst: mit Firewall-- - ping vom Client1 an Server, Adresse: 172.16.1.1 funktioniert; beide Signale (request + reply) laufen �ber tun0 - ping vom Client1 an Server, Adresse: 192.168.100.1 funktioniert; beide Signale (request + reply) laufen �ber tun0, auf eth0 tut sich nix - ping vom Client1 an Rechner im LAN hinterm Server, Adresse: 192.168.100.5 funktioniert NICHT; Signal (request) l�uft �ber tun0, auf eth0 tut sich nix - ping vom Server an Rechner im LAN hinterm Server, Adresse: 192.168.100.5 funktioniert; Signal (request+reply) l�uft �ber eth0 --jetzt: ohne Firewall-- - ping vom Client1 an Server, Adresse: 172.16.1.1 funktioniert; beide Signale (request + reply) laufen �ber tun0 - ping vom Client1 an Server, Adresse: 192.168.100.1 funktioniert; beide Signale (request + reply) laufen �ber tun0, auf eth0 tut sich nix - ping vom Client1 an Rechner im LAN hinterm Server, Adresse: 192.168.100.5 funktioniert; Signal (request+reply) laufen sowohl �ber tun0 als auch eth0 (muss ja sein). ppp0 kann ich nicht �berwachen, es ist einfach zu viel es scheint so, als w�rden s�mtliche Anfragen an 192.168.100.1 von tcpdumb nicht erfasst (z.B: wird die pop3 Abfrage zwar an tun0 angezeigt, nicht jedoch an eth0). Als Ergebnis funktionieren Anfragen an 192.168.100.1 nicht, wenn der Dienst nicht auch an 172.16.1.255 lauscht. Noch ein Hinweis: ich habe die Adresse des Clienten jetzt nicht mehr dynamisch vergeben lassen, sondern manuell festgelegt. Es gab tats�chlich Probleme mit dem Routing; diese sollten nun aber also gel�st sein. Andererseits ist�s jetzt doch anscheinend ein Firewallproblem, denn sonst d�rften die replys ja nicht �ber tun0 laufen, sondern m�ssten direkt �ber ppp0 an mich zur�ckkommen. Hat jemand eventl. eine Ahnung, was ich nun machen kann? Danke! ciao, Stefan
