Re: openvpn + firehol
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
Reply to: