DD-WRT, OpenVPN & IPTABLES.
Geizhals » Forum » Linux-Support » DD-WRT, OpenVPN & IPTABLES. (7 Beiträge, 678 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
DD-WRT, OpenVPN & IPTABLES.
31.05.2006, 22:07:55
Hallo!

Ich bin gerade dabei OpenVPN in einem WRT54G einzurichten und stolpere natürlich über viele Linux Besondereheiten. Bevor ich hier ein Paar IPTables Rules ohne die Auswirkungen genauestens zu kennen setze, frage ich euch lieber was genau sie bewirken werden.

1. OpenVPN ist installiert und lauscht auf Port 25.
2. Es wird tap verwendet, interface tap0 ist vorhanden
3. bridge br0 ist vorhanden
4. tap0 ist an der bridge angebunden
5. in der bridge gesellen sich:
   a) vlan0 (ethernet switch)
   b) eth1 (wlan)
   c) tap0 (eh klar)
6. am vlan1 liegt der WAN port, dort steht auch die chello IP

nun, hier steht http://openvpn.net/bridge.html

Now set up the Linux firewall to permit packets to flow freely over the newly created tap0 and br0 interfaces:

    iptables -A INPUT -i tap0 -j ACCEPT
    iptables -A INPUT -i br0 -j ACCEPT
    iptables -A FORWARD -i br0 -j ACCEPT


sind diese regel angebracht? oder werden sie ein loch ins system schiessen?
soweit ich weiss muss diese regel hier vorhanden sein:
iptables -I INPUT 1 -p tcp --dport 25 -j ACCEPT
wie ist aber mit den anderen 3 aus dem link von openvpn? ziel ist dass road warriors sich per openvpn am router anmelden und so surfen können als ob sie im büro wären. (gesamttraffic soll über den router laufen, auch internettraffic um sniffing zu unterbinden)

anbei ist die derzeitige ip tables von WRT54G:
http://forum.geizhals.at/files/864/iptables.txt

danke!

¸.·´p`·.¸¸.·´a`·.¸¸.·´t`·.¸¸.·´o`·.¸¸.·´s`·.¸
Antworten PM Übersicht Chronologisch
 
Melden nicht möglich
.
Re: DD-WRT, OpenVPN & IPTABLES.
31.05.2006, 23:48:39
Uaaargh - ist iptables-Config laaaange her ;-)

Nur zuerst mal...
Warum Bridging ? Ich habe seinerzeit OpenVPN via Routing implementiert...

Der Vorteil an Routing ist IMHO, daß du
- eine feinere Kontrolle hast
- ich mir nie Bridging angesehen habe ;-)
- du einen schönen, sauberen, definierten Übergang zwischen VPN und LAN schaffst...

Letzteres ist net unwichtig - denn deine road warrior sind tendenziell um Eckhäuser gefährlicher als "normale" LAN-Mitglieder - denn ein Office-PC läßt sich Virensicher hinbekommen, Roadwarrior hingegen...

Mir ist auch das setup noch nicht ganz klar...

LAN == RTR-ETH == Br0 == WLAN == Road-Warrior ?

Denn das papßt ja nicht so ganz zu deiner Config-beschreibung (eth1 als WLAN ist sowieso seeehr unlinuxy ;-)

Tatsächlich solltest könntest du die 3 iptables-Regeln verwenden, um mal jeden Traffic zu erlauben - und dich um die Einfallstore kümmern:
(Achtung, kann gerade net testen und ist laaang her - Teste es nur, wenn du den RTR restarten darfst !):


iptables -I INPUT -i eth1(oder wie auch immer WLAN benammst ist) -p tcp --dport '!' 5000 -j DROP

Das sollte jeden TCP-Verkehr, der über eth0 reinkommt und nicht auf port 5000 geht (damals Standard-OpenVPN) verwerfen.

dann

iptables -I INPUT -i eth1 -p udp -j DROP
iptables -I INPUT -i eth1 -p icmp -j DROP

allen udp- und icmp-Verkehr wegwerfen.

Ziel dabei ist, daß man aus dem WLAN dann eben ausschließlich auf Port 5000 darf - und somit mal sichergestellt ist, daß sich keiner "Vorbeimogeln" kann.

Nun wird's wohl stressiger - denn ohne Routing wird die Regel u.U. komplexer. Wir wollen den VPN-Verkehr (der aus den taps rausfliegt) limitieren:

iptables -I INPUT -i tap+ -j DROP
iptables -I INPUT -i tap+ -p tcp --dport erlaubter Port  -j ACCEPT
iptables -I INPUT -i tap+ -p tcp --dport anderer erlaubter Port  -j ACCEPT

die Idee ist wieder, jeden Verkehr aus tap+ mal zu verbieten und davor dann die Regeln einzufügen, die wir erlauben...

Habe das aber echt 2 Jahre oder so net mehr gemacht... Sorry.

EDIT:
Alternativ für den ersten Teil:

iptables -I INPUT -i eth1 -j DROP
iptables -I INPUT -i eth1 --dport 5000 -j ACCEPT

Würde bedeuten, daß alles von eth0 weggeworfen wird - außer Zielport 5000.



01.06.2006, 00:00 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier
Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
..
Re(2): DD-WRT, OpenVPN & IPTABLES.
01.06.2006, 00:24:23
Nur zuerst mal...
Warum Bridging ? Ich habe seinerzeit OpenVPN via Routing implementiert...


weil da fahrt die eisenbahn drüber und ich bei tap angefangen habe. nachher kommt eh tun dran. primär ist es jetzt eine lernimplementierung.

Letzteres ist net unwichtig - denn deine road warrior sind tendenziell um
Eckhäuser gefährlicher als "normale" LAN-Mitglieder - denn ein Office-PC läßt
sich Virensicher hinbekommen, Roadwarrior hingegen...


der router wird vorerst nur road-warriors versorgen, pc sind auf einer anderen lan.

Mir ist auch das setup noch nicht ganz klar...

LAN == RTR-ETH == Br0 == WLAN == Road-Warrior ?

Denn das papßt ja nicht so ganz zu deiner Config-beschreibung (eth1 als WLAN
ist sowieso seeehr unlinuxy ;-)


bei wrt54g ist es halt so implementiert. hier ein schema:

          |--- vlan0 (switch)
br0 --- |--- eth1 (wlan)
          |--- tap0 (openvpn)

http://upload.wikimedia.org/wikipedia/commons/0/0f/WRT54G_internal_architecture.png

Tatsächlich solltest könntest du die 3 iptables-Regeln verwenden, um mal jeden
Traffic zu erlauben


DAS ist genau die frage, impliziert nicht das hinzufügen von tap0 in die brücke br0 dass sämtlicher traffic zugelassen wird?

wieso sehe ich nicht im iptables ähnliche regel für wlan/lan? sind diese regel in der tat notwendig? was sagen sie genau aus?

-----
andere punkte entsprechen genau deine openvpn implementierung |-D ins detail möchte ich noch nicht gehen, zuerst soll es mal funktionieren als ob man am router angeschlossen wäre.

¸.·´p`·.¸¸.·´a`·.¸¸.·´t`·.¸¸.·´o`·.¸¸.·´s`·.¸
01.06.2006, 00:46 Uhr - Editiert von patos, alte Version: hier
Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
...
Re(3): DD-WRT, OpenVPN & IPTABLES.
01.06.2006, 10:25:42
iptables:
-I bedeutet "Insert ganz vorne"
-A bedeutet "Append ganz hinten".
- danach die Chain - INPUT/FORWARD/OUTPUT
-i bedeutet das Interface
-j ZIEL - wo er hinspringen soll, wenn die Regel matcht.


    iptables -A INPUT -i tap0 -j ACCEPT
    iptables -A INPUT -i br0 -j ACCEPT
    iptables -A FORWARD -i br0 -j ACCEPT


Diese 3 Regeln sagen also aus, daß sie ganz hinten im Regelwerk mal jeden Traffic erlauben, der von tap0 oder br0 reinkommt - und daß br0 forwarden darf - wenn nicht vorher eine andere Regel gegriffen hat (wegen -A).

Grundsätzlich gehe ich bei iptables immer wie folgt vor:
Jede Distri bringt ja ihre eigenen Regeln mit - bei SuSE zB sehr umfangreich. Also mal alles auf default machen lassen - dann klappt's mit allen Tools - danach ganz vorne (-I) in dem Regelwerk eingreifen und diverses untersagen. Das beantwortet auch deinen Sorgenpunkt... Natürlich erlaubst du damit allen Verkehr - den du nicht vorher mit "-I ... -j DROP" verworfen hast.

Wenn es sich übrigens um verschiedene Lans handelt, bist mit br0 AFAIK ganz falsch unterwegs... br0 ist eben AFAIK nur ne bridge, die man verwendet, wenn es sich um das selbe LAN handelt... Beispiel:
192.168.0.0/24er-Lan.
192.168.0.1-100 PC's
192.168.0.101-200 Road warriors

Davon würde ich eben abraten... - einfach weil die Config für mich einfacher wäre, wenn man die Lans bewußt trennen kann. zB 2 Lans:
192.168.0.0/25 und 192.168.0.128/25 - eines für LAN, eines für Roadwarrior.

Einziger Nachteil der Routing-Lösung: Broadcasts gehen nicht mehr durch - wäre mir aber an sich wurscht...




Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
 

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung