Guten Tag Stefan Schilling, ACHTUNG: NACHTRAG!
Am Donnerstag, 24. M�rz 2005 um 00:29 schrieb Stefan Schilling: > 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. ich hab das jetzt mal ein bischen abge�ndert; die Firewall bekommt nun folgende Kommandos mit �bergeben: iptables -A INPUT -i tun+ -j ACCEPT iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -i tun+ -s 172.16.1.0/24 -d 192.168.100.0/24 -j ACCEPT wenn ich jetzt tcpdumb laufen lasse, kommt Folgendes: debian:/home/stefan# tcpdump -i eth0 [...] 01:02:32.412887 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 4865 01:02:32.413064 IP jan.wg > 172.16.1.2: icmp 40: echo reply seq 4865 01:02:37.416557 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 5121 01:02:37.416731 IP jan.wg > 172.16.1.2: icmp 40: echo reply seq 5121 01:02:42.426083 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 5377 01:02:42.426264 IP jan.wg > 172.16.1.2: icmp 40: echo reply seq 5377 01:02:47.429961 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 5633 01:02:47.430138 IP jan.wg > 172.16.1.2: icmp 40: echo reply seq 5633 01:02:52.442340 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 5889 01:02:52.442521 IP jan.wg > 172.16.1.2: icmp 40: echo reply seq 5889 01:02:57.446333 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 6145 01:02:57.446507 IP jan.wg > 172.16.1.2: icmp 40: echo reply seq 6145 128 packets captured 128 packets received by filter 0 packets dropped by kernel debian:/home/stefan# und in einem anderen Fenster: debian:/etc/firehol# tcpdump -i tun0 tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes [...] 01:02:32.412778 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 4865 01:02:37.416483 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 5121 01:02:42.425994 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 5377 01:02:47.429882 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 5633 01:02:52.442256 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 5889 01:02:57.446259 IP 172.16.1.2 > jan.wg: icmp 40: echo request seq 6145 23 packets captured 23 packets received by filter 0 packets dropped by kernel debian:/etc/firehol# Der ping kommt nat�rlich nicht beim XP - Clienten an. Vielleicht -hoffentlich- hilft das ja weiter. > Hat jemand eventl. eine Ahnung, was ich nun machen kann? > Danke! > ciao, > Stefan
