Openvpn : Routing Problem seit TAP

[lynckmeister]

ja
vpnserver - router - internt - fritzbox - clients

ich hatte das mit tun , da geht ja auch alles via routing. das spannende warum ich das hier machen will ist ja , dass ich EIN netzwerk habe und broadcasts darueber gehen.

 

[stinkstiefel]

Das broadcast von S1 zu S2 und umgekehrt über VPN gewünscht ist, is mit so weit schon klar. Ich sehe für eine funktionierende Konfiguration allerdings etwas schwarz so lange Clients auf Seite des VPN-Server eine Rolle spielen und diese den Router als Gateway haben und nicht den Server selbst.

 

[dridders]

Fritzbox:
TAP hat die .101, LAN aber die .7. Das ist falsch! Beide Interfaces muessen die gleiche IP haben, oder optional TAP gar keine.

Server:
tap ist down, "ifconfig tap0 up" ausfuehren, KEINE IP zuweisen! eth5 ebenfalls keine IP zuweisen! Dem Interface "lan" auf dem Server die IP 192.168.1.81 zuweisen.

stinkstifel:
Das hilft ihm gar nix weiter, er will ja eben ein grosses und nicht mehrere kleine Netze haben, andernfalls hat er auch zig Broadcast-Domains, die er aber nicht brauchen kann, siehe oben. Was als Gateway eingetragen ist ist auch Wurst, da gar kein Gateway ins Spiel kommt, es befinden sich schliesslich alle Rechner im gleichen IP-Netz bei einer Bridge. Und die Kiste hat nicht nur 1 NIC, sondern 2, naemlich ETH5 udn TAP0, und da brauchts logischerweise eine Bridge um die zu einer Broadcastdomain zu verbinden.

 

[MaxMuster]

Anmerkung: Das TAP Interface darf schon eine eigene IP haben, solange sie aus dem richtigen Netz ist....
Das Beispiel war natürlich suboptimal, wenn du tap nicht in der lan-Brücke hast, ihm aber dennoch eine IP aus dem Netz gibst. Wenn tap0 auch zu lan gehört, dann sollte das klappen.

Und die Meldungen a la "arp who-has 192.168.1.79 tell 192.168.1.7" sind o.k., hier geht es nicht um Routing sondern um die lokale Zuordnung von Layer2 Adressen ("MAC-Adressen"; im Bespiel versucht die Box [.7] die MAC von 192.168.1.79 zu finden), denn im LAN müssen die Geräte sich ja direkt ansprechen können, und dazu die entsprechende Adressen wissen.


Jörg

 

[dridders]

Jein, dem TAp-Interface eine andere IP zu geben ist gefaehrlich... denn ueber diese IP ist die Box dann nur ueber das TAP-Interface, also aus Richtung Server erreichbar, nicht aber aus dem lokalen Netz, da der lokale Client eine ARP-Anfrage schickt, die Fritz sie dann ueber das entsprechende Interface beantwortet, naemlich TAP0... und die Antwort nur beim Server landet.

 

[stinkstiefel]

Mh, ich hatte tatsächlich nen mächtigen Knoten im Hirn.

 

[MaxMuster]

denn ueber diese IP ist die Box dann nur ueber das TAP-Interface, also aus Richtung Server erreichbar...

Ich habe das genau so schon seit "ewigen Zeiten" am laufen, und die "tap-IP" ist intern und extern erreichbar.
Ist auch schwer vorstellbar, warum es nicht gehen sollte:
- Die Box kriegt die Frage: Wer ist (oder besser: Wer kennt, Stichwort "Proxy-ARP") IP x
- Box geht tief in sich und gelangt zu der Erkenntnis: "Ich bins"
- Die Box schickt eine Antwort an die anfragende IP(!)


Jörg

 

[lynckmeister]

also leute ist ja krass verwirrend

brauch ich nun bridges auf beiden seiten? und ich kann beiden TAP devices jeweilse eine adresse im subnetz geben , muss es aber nicht ?
was genau ist denn nun falsch konfiguriert bei mir?

 

[MaxMuster]

- Ja, wenn das tap-Interface mit einer Brücke verbunden ist, dann muss es keine eigene IP haben (darf es aber).
- TAP macht dann Sinn, wenn du das tap auch mit dem LAN "verbindest", also "brückst".
- Unabhängig von der Art deines Netzes müssen die IP-Adressen schon passen, sonst läufst du in den zu Anfang genannten Fehler:

...
00:45:33.654486 arp who-has 192.168.178.125 tell 10.0.0.1
...

Bei dem Versuch, die IP 192.168.178.125 zu finden wird als "Absende-IP" die TAP-IP 10.0.0.1 genutzt. Der OpenVPN-Client ist nicht 192.168.178.125 und antwortet nicht. Die anderen PCs werden eine "falsche" ARP-Anfrage (wo die fragende IP nicht direkt angeschlossen ist) nicht beantworten.
Willst du also wirklich mit tap arbeiten, broadcasts duch das VPN bringen und so die beiden LANs auf Server- und Clientseite verbinden, so musst du eigentlich auf beiden Seiten den gleichen IP-Kreis nutzen.

Die IPs müssen dabei natürlich verschieden sein, so dass eine mögliche Konfig wäre:

"Servernetz" 192.168.1.0/24, genutzt 192.168.1.1 bis 192.168.1.126
"Clientnetz" 192.168.1.0/24, genutzt 192.168.1.129 bis 192.168.1.254

Die tap-Devices müssen dann wie gesagt gebrückt werden (z.B. mit brctl)


Jörg

 

[stinkstiefel]

So hatte er es ja eigentlich schon und hat wenn ich das richtig verstanden habe für Echo Requests von der Fritz zum Server selbst keine Antwort bekommen.

Meine Idee von gestern war es eigentlich mit dem 10er Netz erst mal zu prüfen ob nicht eventuell noch irgend etwas anderes Faul ist. Denn unabgängig von der Bridge auf Serverseite müssten Echo Requests direkt von der Fritz zum Server und umgekehrt eigentlich eine Antwort bekommen.

 

[lynckmeister]

also ein 10er netz in der mitte hatte ich vorher und das ging einwandfrei.
aber jetzt hab ich es gemäß diverser tutorials auf bridge umgestellt , die server konfig sieht so aus :

dev tap
proto udp

server-bridge 192.168.1.0 255.255.255.0 192.168.1.100 192.168.1.110

client-to-client
duplicate-cn
persist-tun
persist-key
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/ich-server.crt
key /etc/openvpn/keys/ich-server.key

dh /etc/openvpn/keys/dh1024.pem
push "route-gateway 192.168.1.0"

client-config-dir ccd
keepalive 10 120
comp-lzo
port 5004
verb 4

das push route hab ich auch mal weg gelassen , ohne erfolg.
wenn ich auf dem server keine bridge einrichte aber auf der fribo , sehe ich im dumps wiegesagt die ping requests, aber der server antwortet nicht. wenn ich eine bruecke auf dem server einrichte, sehe ich im tap device garnichts mehr...

 

[stinkstiefel]

192.168.1.0 zu verwenden ist keine gute Idee.

 

[lynckmeister]

sollte da die ip vom eth5 stehen ? die 81 ?
oder irgendeine ??

 

[stinkstiefel]

Zum testen ob ping und pong zwischen Server und Fritz klappen kannst du tap0 mal die 192.168.1.1 vergeben und route-gateway 192.168.1.1 verwenden.
Wenn für ping 192.168.1.1 auf der Fritz dann Antworten kommen richtest du die Bridge wie von dridders oben beschrieben ein und prüfst wieder auf die dann vegebene Adresse.