[gelöst] iptables Regeln erstellen für eth0 eth1 und tun0

[slu]

Hallo,

Danke für eure Antworten!

Ist das so OK?

Code: Alles auswählen

wolfserver:~# apt-get install syslog-ng
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut... Fertig
Die folgenden Pakete werden ENTFERNT:
  klogd sysklogd
Die folgenden NEUEN Pakete werden installiert:
  syslog-ng
0 aktualisiert, 1 neu installiert, 2 zu entfernen und 9 nicht aktualisiert.
Es müssen 215kB Archive geholt werden.
Nach dem Auspacken werden 233kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n]
Hole:1 http://ftp2.de.debian.org sarge/main syslog-ng 1.6.5-2.2 [215kB]
Es wurden 215kB in 0s geholt (216kB/s)
(Lese Datenbank ... 16715 Dateien und Verzeichnisse sind derzeit installiert.)
Entferne klogd ...
Stopping kernel log daemon: klogd.
Entferne sysklogd ...
Stopping system log daemon: syslogd.
Wähle vormals abgewähltes Paket syslog-ng.
(Lese Datenbank ... 16692 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacke syslog-ng (aus .../syslog-ng_1.6.5-2.2_i386.deb) ...
Richte syslog-ng ein (1.6.5-2.2) ...
CONSOLE_LOG_LEVEL is of unaccepted value.
KERNEL_RINGBUF_SIZE is of unaccepted value.
Starting system logging: syslog-ng.

wolfserver:~# 

Baue gerade noch den Logrotate ein

[gms]

[quote="slu"]

Code: Alles auswählen

CONSOLE_LOG_LEVEL is of unaccepted value.
KERNEL_RINGBUF_SIZE is of unaccepted value.
Starting system logging: syslog-ng.

Ist nicht ganz ok, sollte aber keine weiteren Problem verursachen. Scheint ein kleiner Bug in der Sargeversion von syslog-ng zu sein.
Kommentiere diese Werte in /etc/default/syslog-ng aus, falls dies noch nicht geschehen ist.

[edit]
Hier ist der Link zum Bugreport:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324816
[/edit]

[slu]

Hi gms,

/etc/default/syslog-ng ist nur das hier enthalten:

Code: Alles auswählen

# If variables is not set here, then the corresponding
# parameters will not be changed.
# If the variables are set, then every invocation of
# syslog-ng's init script will set them using dmesg.
 
# log level of messages which should go to console
# see klogctl(8) or <linux/kernel.h> for details
#
#CONSOLE_LOG_LEVEL=0
 
# Size of the kernel ring buffer used to hold kernel
# messages. 
#KERNEL_RINGBUF_SIZE=16392
#

Sollte ok sein oder?

Hier mal die /var/log/Firewall.log

Code: Alles auswählen

Jan 30 20:54:01 wolfserver kernel: FW:forward:IN=eth1 OUT=eth0 SRC=192.168.89.174 DST=192.168.1.3 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1364 DF PROTO=TCP SPT=2041 DPT=3128 WINDOW=16384 RES=0x00 SYN URGP=0 
Jan 30 20:55:24 wolfserver kernel: FW:forward:IN=eth1 OUT=eth0 SRC=192.168.89.174 DST=192.168.1.3 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1436 DF PROTO=TCP SPT=2046 DPT=3128 WINDOW=16384 RES=0x00 SYN URGP=0 
Jan 30 20:55:27 wolfserver kernel: FW:forward:IN=eth1 OUT=eth0 SRC=192.168.89.174 DST=192.168.1.3 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1438 DF PROTO=TCP SPT=2046 DPT=3128 WINDOW=16384 RES=0x00 SYN URGP=0 
Jan 30 20:55:33 wolfserver kernel: FW:forward:IN=eth1 OUT=eth0 SRC=192.168.89.174 DST=192.168.1.3 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1439 DF PROTO=TCP SPT=2046 DPT=3128 WINDOW=16384 RES=0x00 SYN URGP=0 
Jan 30 20:55:47 wolfserver kernel: FW:output:IN= OUT=eth1 SRC=192.168.89.41 DST=192.168.89.255 LEN=269 TOS=0x00 PREC=0x00 TTL=64 ID=13 DF PROTO=UDP SPT=138 DPT=138 LEN=249  

Nun ist mir klar das daß nicht gehr, aber warum kommte es von eth1?

Auf dem Client ist als Gateway 10.8.0.1 angegeben.

ifconfig sagt

Code: Alles auswählen

wolfserver:~# ifconfig
eth0      Protokoll:Ethernet  Hardware Adresse 00:10:5A:66:E5:88
          inet Adresse:192.168.1.41  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6 Adresse: fe80::210:5aff:fe66:e588/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2469 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1660 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:240948 (235.3 KiB)  TX bytes:608581 (594.3 KiB)
          Interrupt:169 Basisadresse:0xd000

eth1      Protokoll:Ethernet  Hardware Adresse 00:0D:61:91:61:1B
          inet Adresse:192.168.89.41  Bcast:192.168.89.255  Maske:255.255.255.0
          inet6 Adresse: fe80::20d:61ff:fe91:611b/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:155 errors:0 dropped:0 overruns:0 frame:0
          TX packets:252 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:14088 (13.7 KiB)  TX bytes:22679 (22.1 KiB)
          Interrupt:193 Basisadresse:0xe400

lo        Protokoll:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:786 errors:0 dropped:0 overruns:0 frame:0
          TX packets:786 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:92892 (90.7 KiB)  TX bytes:92892 (90.7 KiB)

tun0      Protokoll:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet Adresse:10.8.0.1  P-z-P:10.8.0.2  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

wolfserver:~#

und route sagt

Code: Alles auswählen

wolfserver:~# route
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
localnet        *               255.255.255.0   U     0      0        0 eth0
192.168.89.0    *               255.255.255.0   U     0      0        0 eth1
default         192.168.1.99    0.0.0.0         UG    0      0        0 eth0
wolfserver:~# 

Nun verstehe ich überhaupt nicht warum die Anfrage nicht über tun0 kommt.

EDIT:
/var/log/syslog meldet

Code: Alles auswählen

Jan 30 20:59:23 wolfserver ovpn-server[1970]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Jan 30 20:59:33 wolfserver ovpn-server[1970]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Jan 30 20:59:43 wolfserver ovpn-server[1970]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)

[gms]

Kannst du noch bitte die Ausgabe von "route -n" vom Client posten, bzw von "route print" falls das ein Windows Rechner ist

[slu]

Hi gms,

Code: Alles auswählen

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Dokumente und Einstellungen\Samuel>route print
===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 ff f3 fd ef a7 ...... TAP-Win32 Adapter V8 #2 - Paketplaner-Miniport
0x3 ...00 ff be 8a 49 af ...... TAP-Win32 Adapter V8 - Paketplaner-Miniport
0x10005 ...00 0b cd 86 08 39 ...... National Semiconductor Corp. DP83815/816 10/
100 MacPhyter PCI Adapter - Paketplaner-Miniport
0x10006 ...00 80 5a 35 1e 20 ...... Conceptronic 54g Wireless PC-Card
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0         10.8.0.1  192.168.89.174       25
         10.8.0.0    255.255.255.0         10.8.0.5        10.8.0.6       1
         10.8.0.4  255.255.255.252         10.8.0.6        10.8.0.6       30
         10.8.0.6  255.255.255.255        127.0.0.1       127.0.0.1       30
   10.255.255.255  255.255.255.255         10.8.0.6        10.8.0.6       30
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
     192.168.89.0    255.255.255.0   192.168.89.174  192.168.89.174       25
   192.168.89.174  255.255.255.255        127.0.0.1       127.0.0.1       25
   192.168.89.255  255.255.255.255   192.168.89.174  192.168.89.174       25
        224.0.0.0        240.0.0.0         10.8.0.6        10.8.0.6       30
        224.0.0.0        240.0.0.0   192.168.89.174  192.168.89.174       25
  255.255.255.255  255.255.255.255         10.8.0.6        10.8.0.6       1
  255.255.255.255  255.255.255.255         10.8.0.6           10005       1
  255.255.255.255  255.255.255.255         10.8.0.6               2       1
  255.255.255.255  255.255.255.255   192.168.89.174  192.168.89.174       1
Standardgateway:          10.8.0.1
===========================================================================
Ständige Routen:
  Keine

C:\Dokumente und Einstellungen\Samuel>

[gms]

Das Windows-Routing werde ich wohl nie ganz kapieren. Möchte zum Beispiel wissen woher die Einträge für 10.8.0.4, 10.8.0.5 und 10.8.0.6 kommen. Gut das ist nicht unser derzeitiges Problem.
Also wenn ich das richtig interpretiere (wovon ich nicht 100 prozentig überzeugt bin), ist zwar das Standardgateway auf 10.8.0.1 gesetzt, gesucht wird dieser Host jedoch über die Schnittstelle 192.168.89.174 und das scheint genau das Problem zu sein. Dadurch gehen alle Verbindungsversuche über eth1.

[edit]
willst du überhaupt, daß das Defaultgateway am Client auf 10.8.0.1 gesetzt wird ? Normalerweise macht man das nur, wenn der gesamte Netzwerkverkehr über das VPN gehen soll. Also wenn am Client auch über das VPN ins Internet geroutet werden soll.
[/edit]

[slu]

Hi gms,

ja das ist absicht weil ich möchte alle Verbindungen die übers WLAN gehen durch VPN jagen.

Oder liegt das Problem an dem VPN-Server das dieser die IP/Netzwerkkarte so weitergibt und nicht die IP/Virtuele interface vom VPN?

[gms]

Wie setzt du das Defaultgateway am Client ? Das kannst du ja erst, wenn die VPN Verbindung steht auf 10.8.0.1 umsetzen.
Das Defaultgateway muß ja irgendwie auch über den VPN Client (bzw Server) zu setzen sein, da kenne ich mich allerdings unter Windows überhaupt nicht aus. Kommst du damit klar ?

Noch eine kleine Anregung für dein Firewallscript
Damit du nicht das Firewall.log mit Netbios Meldungen zugemüllt bekommst, so wie hier

Code: Alles auswählen

Jan 30 20:55:47 wolfserver kernel: FW:output:IN= OUT=eth1 SRC=192.168.89.41 DST=192.168.89.255 LEN=269 TOS=0x00 PREC=0x00 TTL=64 ID=13 DF PROTO=UDP SPT=138 DPT=138 LEN=249 

solltest du noch diese Regeln, vor den Logging Regeln einfügen

Code: Alles auswählen

 # drop outgoing netbios messages
 iptables -A OUTPUT -o eth1 -p udp  --dport 137:138 -j DROP
 iptables -A FORWARD -o eth1 -p udp --dport 137:138 -j DROP

[slu]

Hi gms,

Code: Alles auswählen

Wie setzt du das Defaultgateway am Client ? Das kannst du ja erst, wenn die VPN Verbindung steht auf 10.8.0.1 umsetzen.
Das Defaultgateway muß ja irgendwie auch über den VPN Client (bzw Server) zu setzen sein, da kenne ich mich allerdings unter Windows überhaupt nicht aus. Kommst du damit klar ?

Den trage ich über die Netzwerkeigenschaften ein (win). Der VPN-Server ist ein OpenVPN auf meinem Linuxserver/debian.

Ich frag mich aber langsam ob ich überhaupt den richtigen Gateway angegeben habe.

Code: Alles auswählen

tun0      Protokoll:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet Adresse:10.8.0.1  P-z-P:10.8.0.2  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Hier steht nämlich was von 10.8.0.1 und 10.8.0.2 und Win behauptet das es seine VPN IP über dem DHCP-Server 10.8.0.5 bekommen hat.

Das dämmert mir auch nicht so ganz.

Als nächstes werde ich mal mein debian auf dem Notebook booten und da mal versuchen den Gateway zu setzen.

[slu]

So ich habe nochmal etwas probiert.

Wenn ich keinen Gateway eintrage steht nichts in der Firewall.log.
Auch wenn ich 10.8.0.2 und 10.8.0.5 (aus Verzweiflung) eintrage ist nichts in der Firewall.log

Es steht nur etwas in der Firewall.log wenn der Gateway 10.8.0.1 (OpenVPN-Server) angegeben ist, was bedeutete das Problem MUSS meiner Meinung nach am Server liegen.

Nur wo? Da hab ich dann keine Idee mehr.

EDIT:
Die einzigste Idee die ich nun noch habe ist NATen, also quasi auf 10.8.0.1:3128 zugreifen und bei 192.168.1.3:3128 rauszukommen.

EDIT2: Könntest du mir helfen eine NAT Regel zu erstellen?

[gms]

Code: Alles auswählen

Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0         10.8.0.1  192.168.89.174       25
         10.8.0.0    255.255.255.0         10.8.0.5        10.8.0.6       1

Wenn du als Gateway 10.8.0.2 und 10.8.0.5 einträgst laufen die vom Client über das Interface 10.8.0.6 so wie sie sollen (siehe oben 2te Zeile).
Gibst du als Gateway 10.8.0.1 ein wird die Schnittstelle 192.168.89.174 (also eth1 !!!)genommen (siehe oben 1te Zeile)
Daher kommen die Unterschiede im Firewall.log

Das es nicht am Server liegt, siehst du ja auch daran, daß die Packete über eth1 reinkommen und darauf wo die Packete reinkommen hat doch der Server keinen direkten Einfluß

Das Gateway mußt du am Client irgendwie über die Einstellungen der VPN Verbindung einstellen

Gruß
gms

[gms]

Probier einmal als Gateway die IP der VPN Verbindung des Clients zu nehmen,vielleicht funktionierts mit der besser

[slu]

Dachte ich auch schon aber das wars nicht.

Nur wenn ich die VPN-Server IP 10.8.0.1 als Gateway eintrage sehe ich den besagten Zugriff in der Firewall.log.

Alles andere läuft ins leere. Darum bin ich mir sicher das die Verbindung nur über das VPN tun0 interface reinkommen kann.

Würde es gerne mal mit NATen versuchen, könntest du mir da unter die Arme greifen?

Habe übrigens noch ein iptables -A FORWARD -i tun0 -j ACCEPT hinzugefügt, hatte aber auch nicht den erhofften efekt.

[gms]

Was hast du den jetzt wirklich für eine VPN IP unter Windows ? Da ist ja ein ziemlicher Durcheinander in der Routing Tabelle.

Die einzigste Idee die ich nun noch habe ist NATen, also quasi auf 10.8.0.1:3128 zugreifen und bei 192.168.1.3:3128 rauszukommen.

Dein NATen verstehe ich nicht:
Dein derzeitiges Problem ist, daß der Verbindungsaufbau von eth1 kommt und nicht von tun0. Was willst du jetzt mit diesen Verbindungsversuchen machen:
a) auf tun0 forwarden ?
macht wenig Sinn, dann gehen diese Verbindungen ziemlich elegant an deinem VPN vorbei
b) auf eth0 forwarden ?
ist im Prinzip der gleiche Mist

Bei diesem Problem wird dir ein NATen nicht helfen, wenn die Packete über eth1 reinkommen, kannst du am Server nicht viel mehr damit anfangen, als diese wegzuschmeißen.

Gruß
gms

[gms]

Wir benötigen auf alle Fälle erst einmal Packete die den Server auf tun0 erreichen und nicht wie aus dem Firewall Log ersichtlich von eth1. Und das kannst du nur am Client beeinflußen. Dort stimmt etwas grundlegend nicht, woher kommen die vielen 10.8.0.x er IP*s her ?
Ob eine Verbindungsversuch über tun0 am Server reinkommt, kannst du mit folgendem Kommando überprüfen:

Code: Alles auswählen

iptables -nvL FORWARD | grep tun0

Dann siehst du in der ersten Spalte zu jeder Regel die Anzahl der Pakete für die diese Regel gegolten hat. Wenn eine der tun0 Regeln schon Packete erhalten hat, dann stimmt das Routing am Windowsclient.

Klappt dann die Verbindung noch immer nicht, und du kannst das nicht über das Defaultgateway in deinem eth0 steuern, dann kannst du noch folgende Zeile in deinem Script hinzufügen.

Code: Alles auswählen

iptables -A POSTROUTING -t nat -i tun0 -o eth0 -j SNAT --to <eth0 adresse am server>

Diese macht dann schon auch (S)NAT aber eben nur für Packete von tun0 und eigentlich solltest du diese Regel nicht benötigen, da ja Verbindungen über eth1 auch ohne SNAT funktioniert haben.

Gruß
gms

[slu]

Hi gms,

das ist ja echt in blödes Problem.
Ich habe den VPN-Server nach dieser Anleitung installiert:
https://knecht.homelinux.net/phpBB2/vie ... c&&start=0

Dann ergibt auf dem Server ein ifconfig

Code: Alles auswählen

tun0      Protokoll:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet Adresse:10.8.0.1  P-z-P:10.8.0.2  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:37 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX bytes:2774 (2.7 KiB)  TX bytes:2256 (2.2 KiB)

wolfserver:~#

Auf dem Winclient hat das VPN-Interface die IP 10.8.0.6 und diese hat es vom DHCP bekommen welcher die IP 10.8.0.5 hat (so steht es unter Status).

Die WLAN-Karte hat die IP 192.168.89.174 und als Standartgateway 10.8.0.1 eingetragen.

Ein Ping vom Client auf die laut Anleitung Server VPN IP 10.8.0.1 ist positive.
Ebenso ist ein Ping vom Server auf 10.8.0.6 positive.

route print sieht nun schlanker aus, das TUN-VPN Interface war versehentlich zwei mal auf dem Winclient installiert.

Code: Alles auswählen

===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 ff be 8a 49 af ...... TAP-Win32 Adapter V8 - Paketplaner-Miniport
0x10004 ...00 0b cd 86 08 39 ...... National Semiconductor Corp. DP83815/816 10/
100 MacPhyter PCI Adapter - Paketplaner-Miniport
0x10005 ...00 80 5a 35 1e 20 ...... Conceptronic 54g Wireless PC-Card
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0         10.8.0.1  192.168.89.174       25
         10.8.0.0    255.255.255.0         10.8.0.5        10.8.0.6       1
         10.8.0.4  255.255.255.252         10.8.0.6        10.8.0.6       30
         10.8.0.6  255.255.255.255        127.0.0.1       127.0.0.1       30
   10.255.255.255  255.255.255.255         10.8.0.6        10.8.0.6       30
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
     192.168.89.0    255.255.255.0   192.168.89.174  192.168.89.174       25
   192.168.89.174  255.255.255.255        127.0.0.1       127.0.0.1       25
   192.168.89.255  255.255.255.255   192.168.89.174  192.168.89.174       25
        224.0.0.0        240.0.0.0         10.8.0.6        10.8.0.6       30
        224.0.0.0        240.0.0.0   192.168.89.174  192.168.89.174       25
  255.255.255.255  255.255.255.255         10.8.0.6           10004       1
  255.255.255.255  255.255.255.255         10.8.0.6        10.8.0.6       1
  255.255.255.255  255.255.255.255   192.168.89.174  192.168.89.174       1
Standardgateway:          10.8.0.1
===========================================================================
Ständige Routen:
  Keine

C:\Dokumente und Einstellungen\Samuel>

Code: Alles auswählen

wolfserver:~# iptables -nvL FORWARD | grep tun0
   11   806 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     tcp  --  tun0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21 state NEW
    0     0 ACCEPT     tcp  --  tun0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3128 state NEW
wolfserver:~#

So dann hab ich mal am Server iptables -P INPUT ACCEPT und OUTPUT ACCEPT gemacht und kann nun via 10.8.0.1 auf meinen Samba-Server zugreifen.

Aber ich sehe in der Firewall.log keinen einigen Zugriff von tun0.

EDIT:
In der syslog sieht man die Zugriffe:

Code: Alles auswählen

Jan 31 01:12:49 wolfserver ovpn-server[1970]: client1/192.168.89.174:1088 MULTI: Learn: 10.8.0.6 -> client1/192.168.89.174:1088
Jan 31 01:12:49 wolfserver ovpn-server[1970]: client1/192.168.89.174:1088 MULTI: primary virtual IP for client1/192.168.89.174:1088: 10.8.0.6
Jan 31 01:15:09 wolfserver smbd[3438]: connect from 10.8.0.6 (10.8.0.6)
Jan 31 01:15:09 wolfserver smbd[3439]: connect from 10.8.0.6 (10.8.0.6)
Jan 31 01:15:12 wolfserver smbd[3440]: connect from 10.8.0.6 (10.8.0.6)
Jan 31 01:16:18 wolfserver syslog-ng[1955]: STATS: dropped 0
Jan 31 01:16:23 wolfserver smbd[3451]: connect from 10.8.0.6 (10.8.0.6)

EDIT2:
Das mit dem POSTROUTING hab ich jetzt nicht mehr ausprobiert, ist zu spät geworden...

Vielen Dank für deine Hilfe und Gedult!

[slu]

@ gms,

hast du eine Idee warum ich keinerleih Zugriffe in der Firewall.log von tun0 sehe?

Das zugreifen auf Samba via 10.8.0.1 ging auch erst nachdem ich INPUT/OUTPUT ACCEPT gemacht habe.

Aber wie kann das sein? Ich habe doch...

Code: Alles auswählen

iptables -A INPUT -i tun0 -j ACCEPT
iptables -A OUTPUT -o tun0 -j ACCEPT 

... in mein Script eingebaut.

So langsam glaube ich das Problem liegt doch an meinem VPN-Server.

Vieleicht hat es etwas mit der virtuellen Netzwerkkarte (tun0) zu tun?

[gms]

Code: Alles auswählen

wolfserver:~# iptables -nvL FORWARD | grep tun0
   11   806 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0
wolfserver:~#

zumindest kurzfristig sind Pakete über tun0 reingekommen, wie diese Ausgabe beweist

Hier dürftest du übrigens wieder einen Fehler eingebaut haben. Diese Ausgabe entspricht der Regel

Code: Alles auswählen

iptables -i tun0 -j ACCEPT

Du hast hier anscheinend die Optionen " -m state --state ESTABLISHED,RELATED " entfernt und dafür aber ein "-i tun0" hinzugefügt.
Zu diesem Zeitpunkt, sind also Paket von tun0 reingekommen, es konnten aber keine Antwortpakete wieder zurück. Vielleicht hätte ohne dieser Änderung zu diesem Zeitpunkt sogar alles funktioniert.

Du mußt öfters überprüfen, wie sich deine Änderungen am System auswirken. Entweder über "iptables -nvL" oder besser über zusätzliches Logging. Du kannst dir auch über den Befehl "logger" (Packet: bsdutils) zusätzliche Markierungen in deinem Firewall.log setzen oder Notizen reinschreiben.

Code: Alles auswählen

logger "FW: jetzt Teste ich ob ich mich zu dem Server A verbinden kann"

wichtig ist natürlich der Prefix "FW:"

Sehr zu empfehlen sind natürlich auch Programme wie tcpdump oder ethereal, mit denen du den Netwerkverkehr mitschneiden kannst.
Versuche die Pakete zu "verfolgen": Zuerst müssen sie über tun0 reinkommen, sobald du dort Paket siehst, kannst du überprüfen ob diese auch bei eth0 rausgehen. Danach muß eine Antwort bei eth0 reinkommen und bei tun0 wieder rausgehen. Wenn einmal beide Richtungen funktionieren, dann hast du die Lösung.

Gruß
gms

[slu]

Hi gms,

Code: Alles auswählen

wolfserver:~# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
wolfserver:~# echo "1" > /proc/sys/net/ipv4/ip_forward
wolfserver:~#

Server IP 192.168.89.41
Client IP 192.168.89.174 Gateway 192.168.89.41

Ping auf 192.168.1.11 geht nicht mehr vom Client, Ping vom Server geht sowohl auf 192.168.89.174 also auch auf 192.168.1.11

Nachdem nun nicht mal das mehr geht (was vor zwei Tagen ja noch der Fall war) leg ich die ganze Routing VPN Geschichte (vorerst?) zu den ungelösten akten.

Irgendwo steckt nun total der Wurm drin.

Ich bedanke mich für deine Gedult und deine Hilfe!

[slu]

Hallo,

ok ich geb es ja zu, das Problem lässt mich nicht in ruhe!

Gibt es irgendein Grund warum

Code: Alles auswählen

echo "1" > /proc/sys/net/ipv4/ip_forward

nicht mehr funktionieren könnte?

Durch ein cat sehe ich auch das eine 1 drin steht, wurde also übernommen.

Wenn iptables alles auf ACCEPT steht und alles andere mit iptables -F gelöscht wurde MUSS das ROUTUING doch GEHEN oder?

Ich habe es auch mit zwei verschiedenen Clients und Betriebssystemen ausprobiert.

Mir fällt gerade noch was ein, ich könnte ja eigentlich nur das Loggin in iptables aufnehmen.

[gms]

Kommt drauf an was du alles probiert hast.
Nat Einträge z.B. müssen extra gelöscht werden (kannst du mit "iptables -F -t nat" löschen und mit "iptables -nvL -t nat" angucken). Ansonsten liegt das ziemlich sicher an veränderten Routingeinträgen, bzw an falschem Defaultgateway auf einem der beteiligten Rechner.

Gruß
gms

[slu]

Hi gms,

ok es geht wieder, ich Esel habe auf dem zu pingenden Empfänger PC vergessen den Gateway einzutragen...

Nun hab ich wieder die gleiche Ausgangsituation.

FORWARD ist auf ACCEPT gesetzt, mit dem Client greife ich problemlos auf das andere Subnetz zu.

Das interesante ist nun, wenn ich auf dem Client als Gateway 192.168.89.41 (debian server) eintrag geht es. Ebenso wenn ich auf dem Client als Gateway 10.8.0.1 (openvpn server auf debian server) eintrage.

Das verrückte hierbei in der Firewall.log steht immer das selbe (eth1 rein eth0 raus), nie erscheint das Interface tun0

http://nopaste.debianforum.de/2342

Trage ich keinen Gateway auf dem Client ein kann der logischerweise das andere Subnetz nicht erreichen.

Der Client hängt via VPNServer an eth1 Hardwaremässig, Softwaremässig an tun0.

Ich bin der Meinung das das Problem irgendwo am VPN Server liegen muss.
Vieleicht gibt er als Quelle das Hardwareinterface an?

Ich hatte dann noch probiert zu NATen:

Code: Alles auswählen

iptables -A PREROUTING -t nat -p tcp -d 10.8.0.1 --dport 3128 -j DNAT --to 192.168.1.3:3128

leider hatt das auch nicht funktioniert.

Ich habe knecht gebeten sich einmal den Beitrag anzuschauen, er hatte auch die OpenVPN Anleitung geschrieben. Sobald er Zeit hat schaut er sich es an.

[edit]
Es geht, mit NAT!

Code: Alles auswählen

iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 3128 -j DNAT --to 192.168.1.3:3128

Nun komme ich via 10.8.0.1:3128 auf 192.168.1.3:3128

In der Firewall erscheint jedoch nichts, ich denke das wird auch nicht gelogt weil es nicht angegben (Regel) ist, oder lieg ich da falsch?
[/edit]

[gms]

danke für die PN und herzliche Gratulation!

Diese schon mehrfach von dir geäußerte Theorie, kann ich nicht bestätigen:

Code: Alles auswählen

Der Client hängt via VPNServer an eth1 Hardwaremässig, Softwaremässig an tun0. 

Ich bin der Meinung das das Problem irgendwo am VPN Server liegen muss. 
Vieleicht gibt er als Quelle das Hardwareinterface an?

Hier die "Beweise" das diese Theorie nicht stimmen kann:
a)

Code: Alles auswählen

wolfserver:~# iptables -nvL FORWARD | grep tun0
   11   806 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0
wolfserver:~#

Diese Rule behandelt nur Pakete, wenn diese vom tun0 reinkommen. In der ersten Spalte siehst du das 11 Pakete im tun0 Interface reingekommen sind.

b) letztendlich baut ja deine Lösung auch auf die Abfrage des tun0 Interfaces auf und widerspricht daher deiner eigenen Theorie

[edit]
Es geht, mit NAT!

Code: Alles auswählen

iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 3128 -j DNAT --to 192.168.1.3:3128

Nun komme ich via 10.8.0.1:3128 auf 192.168.1.3:3128

Es bleibt daher leider ein Rätsel, warum das bei dir ohne DNAT nicht funktioniert.
Der Zugriff von eth1 in das eth0 Netz hat ja auch ohne DNAT funktioniert. Das gleiche muß natürlich auch über das tun0 Interface möglich sein.

Aber du bist mit dieser Lösung ja anscheinend zufrieden und es gilt "never change a running system".

Gruß
gms

[slu]

Hi gms,

du hattest zu 100% recht
(im übrigen hab ich daran nie gezweifelt!)

Ich habe nun auf meinem VPN Server noch folgendes in die Konfiguration hinzugefügt:

Code: Alles auswählen

push "route 192.168.1.0 255.255.255.0"

Nun geht es, er legt nun die richtigen Routen selbst fest.

EDIT: Leider klappt das starten der Firewall per inittab nicht. Habe deshalb mal einen neuen Beitrag gestartet http://www.debianforum.de/forum/viewtopic.php?t=61883