It is currently 22.11.2017 13:10


All times are UTC




Post new topic Reply to topic  [ 13 posts ] 
Author Message
 Post subject: Client-Verbindung von IPCop zu remote OpenVPN-Server
PostPosted: 23.04.2006 11:49 
Tripple-DES
Tripple-DES

Joined: 15.03.2006 23:29
Posts: 11
Hallo zusammen,
folgendes Szenario.

Habe ein IPCop mit Zerina laufen. OpenVPN hört auf Interface Rot. Funktioniert alls wunderbar. Danke noch mal für Zerina an dieser Stelle!

So nun möchte ich allerdings gleichzeitig von IPCop aus eine Client-OpenVPN-Verbindung zu einem externen OpenVPN-Server herstellen.
Dabei soll das Netz hinter dem IPCop auf das Remote-Netz zugreifen können. Dem Remote-Netz/ Server soll allerdings keine Möglichkeit gegeben werden, auf den IPCop oder das Netzt hinter diesem, zu kommen...

Mein bisheriger Ansatz um das umzusetzen sieht wie folgt aus:

In der Client-Konfiguration habe ich festgelegt dass die Verbindung z.B. über das Interface tun1 erstellt werden soll.

Starte das ganze dann als Daemon:
Code:
openvpn --daemon --config client-remote-server.conf

Gebe meinem lokalen Netz Zugriff auf das remote-Netz
Code:
LOCAL_NET = '192.168.127.0/24'
REMOTE_NET = '192.168.120.0/24'

iptables -t nat -A POSTROUTING -s LOCAL_NET -o tun1 -d REMOTE_NET -j MASQUERADE


Wäre das bis dahin richtig so?
Prinzipiell funktioniert auch alles, nur dass der Remote-Server nun auch Zugriff auf den IPCop hat. So kann z.B. das IPCop-HTTP-Interface vom Remote-Server aus aufgerufen werden!
Dass das HTTP-Interface vom Remote-Server aus erreichbar ist, wird wenn ich das richtig sehe durch die openvpnctrl verursacht, da hier iptable-Regeln für den Zerina-OpenVPN-Server pauschal für alle tun-Interfaes gesetzt werden.
Code:
sprintf(str, "/sbin/iptables -A %sINPUT -i tun+ -j ACCEPT", chain);
sprintf(str, "/sbin/iptables -A %sFORWARD -i tun+ -j ACCEPT", chain);


Bin nicht wirklich fit was die gesamte Materie angeht. Also wäre dankbar zu erfahren ob mein genereller Ansatz überhaupt so richtig ist und wenn ja warum openvpnctrl pauschal iptalbes-Regeln für alle tun-Interfaces setzt.


Gruß,
Tom

p.s.
Ist schon abzusehen wann ungefähr mit der ersten net2net-Zerina-Version zu rechnen ist. Wird es damit möglich sein ein solches Szenario abzubilden?
Falls Ihr noch wen zum Testen sucht. Ich stände zur Verfügung ;)


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 23.04.2006 12:03 
Blowfish
Blowfish

Joined: 18.04.2005 19:31
Posts: 732
Hallo Tom,

also and der net2net wird derzeit stark gebastelt, ich hatte schon so oft einen Möglichen Termin genannt, den ich jedoch nicht einhalten konnte (ist halt ein Freizeitprojekt).

Bzgl. net2net schweben mir unterschiedliche Konzepte im Kopf herum.

1.) Einmal hätten wir die IPCop typische Netzwerk-zu-Netzwerk Kopplung, die wird auch als erstes fertiggestellt.

2.) Das nächste, wäre den OpenVPN Server zu erweitern, um das Netz hinter den Roadwarrior Clients auch zu routen Stichwort iroute.

Dann könnte man den IPCop als Zentralen VPN Punkt definieren.

Für Deinen Einsatz, schu Dir mal den Parameter iroute an, dieser wird auch beim 2. Konzept zum einsatz kommen.

Gruß
horizont

EDIT

Ja wir werden auf jeden Fall Tester gebrauchen, sobald etwas testbares Fertiggestellt ist, schreibe ich einen kleinen Aufruf


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 23.04.2006 13:09 
Tripple-DES
Tripple-DES

Joined: 15.03.2006 23:29
Posts: 11
Hallo Horizont,

horizont wrote:
also and der net2net wird derzeit stark gebastelt, ich hatte schon so oft einen Möglichen Termin genannt, den ich jedoch nicht einhalten konnte (ist halt ein Freizeitprojekt).

sollte keinesfalls drängelnd wirken ;)

Quote:
Für Deinen Einsatz, schu Dir mal den Parameter iroute an, dieser wird auch beim 2. Konzept zum einsatz kommen.


Ich glaube hier wird dann doch mein mangelndes Verständnis akut, oder ich habe mich in meinem vorherigen Post nicht deutlich genug ausgedrückt :oops:
Ist iroute nicht ein Serverseitiger Parameter?
Mein Ziel, um es noch mal klar zu machen, ist auf dem IPCop eine Client-Verbindung zu einem entfernten OpenVPN-Server herzustellen. Auf diesen entfernten Server hätte ich im Regelfall keinen administrativen Zugriff.
Ich möchte aber meinen IPCop so konfigurieren, dass vom entfernten OpenVPN-Server keine Verbindung zum IPCop möglich sind, also über das tun-Interface der Client-Verbinding keine Dienste wie ssh oder https des IPCops erreichbar sind.

Quote:
Ja wir werden auf jeden Fall Tester gebrauchen, sobald etwas testbares Fertiggestellt ist, schreibe ich einen kleinen Aufruf

Na dann hoffe ich doch mal dass der Aufruf nicht am mir vorbeigeht und ich euch ein wenig helfen kann ...


Gruß,
Tom


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 23.04.2006 14:53 
AES 192 bit
AES 192 bit
User avatar

Joined: 22.12.2005 05:39
Posts: 157
Location: LDK | Hessen
tom wrote:
Ich möchte aber meinen IPCop so konfigurieren, dass vom entfernten OpenVPN-Server keine Verbindung zum IPCop möglich sind, also über das tun-Interface der Client-Verbinding keine Dienste wie ssh oder https des IPCops erreichbar sind.

Wenn Standard-Password Schutz nicht ausreicht, ginge das mit ein DROP in der CUSTOMINPUT chain. Etwa so:
Code:
 /sbin/iptables -A CUSTOMINPUT -i tun1 -j DROP


-> Einfach alles was zum Cop will von IFace tun1 im Mülleimer.

_________________
/* Gruß weizen_42 */

IPCop v1.4.15 with ZERINA (and some more addons)
Bitte beachtet die Forum-Regeln * klick *


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 23.04.2006 15:10 
Tripple-DES
Tripple-DES

Joined: 15.03.2006 23:29
Posts: 11
aehm ja ok,
aber dann nochmal zu der openvpnctrl

es ist doch richtig, dass durch setzten dieser Regeln:

Code:
sprintf(str, "/sbin/iptables -A %sINPUT -i tun+ -j ACCEPT", chain);
sprintf(str, "/sbin/iptables -A %sFORWARD -i tun+ -j ACCEPT", chain);


erst die generelle Erreichbarkeit der Dienste auf allen erzeugten tun-Interfaces "verursacht" wird oder sehe ich das falsch?

Und dann wäre es doch sinniger wenn möglich diese Regel explizit nur auf das benötigte Interface anzuwenden, anstatt erst alles zu erlauben und nachher wieder einschränken zu müssen?

Gruß und danke,
Tom


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 24.04.2006 05:07 
AES 192 bit
AES 192 bit
User avatar

Joined: 22.12.2005 05:39
Posts: 157
Location: LDK | Hessen
tom wrote:
Code:
sprintf(str, "/sbin/iptables -A %sINPUT -i tun+ -j ACCEPT", chain);
sprintf(str, "/sbin/iptables -A %sFORWARD -i tun+ -j ACCEPT", chain);


erst die generelle Erreichbarkeit der Dienste auf allen erzeugten tun-Interfaces "verursacht" wird oder sehe ich das falsch?

das is richtig

tom wrote:
Und dann wäre es doch sinniger wenn möglich diese Regel explizit nur auf das benötigte Interface anzuwenden, anstatt erst alles zu erlauben und nachher wieder einschränken zu müssen?

Nunja, ein Regel in CUSTOMINPUT 'greift' für diese 'Allgemeine tun+ Erlaub Regel'.

Der Regel in OVPN_BLUE_INPUT anpassen könnte man machen durch:
- openvpnctrl.c anpassen, wird aber durch jede ZERINA Update überschreiben
- Regel entfernen in rc.firewall.local und dann ein andere zufügen

_________________
/* Gruß weizen_42 */

IPCop v1.4.15 with ZERINA (and some more addons)
Bitte beachtet die Forum-Regeln * klick *


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 24.04.2006 07:07 
Tripple-DES
Tripple-DES

Joined: 15.03.2006 23:29
Posts: 11
Ja klar. Also ich für mich würde jetzt die rc.firewall.local anpassen,
indem ich einfach die openvpnctrl-Aufrufe rausnehme und dann nur meine eigenen Regeln definiere.
Ich habe das eine tun-Interface für Zerina und dann mindestens noch drei weiter tun-Interfaces für Client-Verbindungen vom IPCop aus.
Da scheint es mir doch richtiger zu sein, generell nichts zu erlauben und dann explizit einzelene Regeln für das jeweilige Interface zu ersetellen?

Aber die eigentliche Frage stellt sich mir doch trotzdem. Warum allgemeine Erlaub-Regeln für tun+ bei Zerina?
Wäre das nicht eine Sache die man generell in Zerina ändern sollte, indem Regeln nur auf das explizit benötigte Interface angewandt werden?

Gruß,
Tom


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 24.04.2006 07:13 
AES 256 bit
AES 256 bit
User avatar

Joined: 04.06.2004 12:08
Posts: 363
Location: Hannover
tom wrote:
Aber die eigentliche Frage stellt sich mir doch trotzdem. Warum allgemeine Erlaub-Regeln für tun+ bei Zerina?
Wäre das nicht eine Sache die man generell in Zerina ändern sollte, indem Regeln nur auf das explizit benötigte Interface angewandt werden?


Ohne den Thread jetzt komplett verfolgt zu haben - das "tun+" ist imho schon seit den ersten ZERINA Versionen drin. Das sollten wir mit auf die ToDo-Liste setzen, oder ?


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 24.04.2006 10:59 
AES 192 bit
AES 192 bit
User avatar

Joined: 22.12.2005 05:39
Posts: 157
Location: LDK | Hessen
Daniel wrote:
Ohne den Thread jetzt komplett verfolgt zu haben - das "tun+" ist imho schon seit den ersten ZERINA Versionen drin. Das sollten wir mit auf die ToDo-Liste setzen, oder ?

Keine Ahnung, hatte doch aber bestimmt ein Grund weshalb tun+ statt tun0 drin ist ?

_________________
/* Gruß weizen_42 */

IPCop v1.4.15 with ZERINA (and some more addons)
Bitte beachtet die Forum-Regeln * klick *


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 24.04.2006 11:45 
Blowfish
Blowfish

Joined: 18.04.2005 19:31
Posts: 732
weizen_42 wrote:
Daniel wrote:
Ohne den Thread jetzt komplett verfolgt zu haben - das "tun+" ist imho schon seit den ersten ZERINA Versionen drin. Das sollten wir mit auf die ToDo-Liste setzen, oder ?

Keine Ahnung, hatte doch aber bestimmt ein Grund weshalb tun+ statt tun0 drin ist ?


hatte auch einen (lange Geschichte) , kurz: Multiple OpenVPN Instanzen, ist in der n2n Version auch etwas anders aufgebaut der werden den Instanzen die tun Adapter fest zugewiesen.

Wovon ich allerdings abgerückt bin, ist spezielle Filtermechanissmen in ZERINA zu integrieren, das gibt es wesentlich leistungsfähigere (vor allen Dingen sind die schon fertig) Lösungen (z.B. BOT)

horizont


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 24.04.2006 12:26 
Tripple-DES
Tripple-DES

Joined: 15.03.2006 23:29
Posts: 11
Quote:
hatte auch einen (lange Geschichte) , kurz: Multiple OpenVPN Instanzen, ist in der n2n Version auch etwas anders aufgebaut der werden den Instanzen die tun Adapter fest zugewiesen.

Wovon ich allerdings abgerückt bin, ist spezielle Filtermechanissmen in ZERINA zu integrieren, das gibt es wesentlich leistungsfähigere (vor allen Dingen sind die schon fertig) Lösungen (z.B. BOT)


Naja das klingt doch sehr gut und sinnvoll alles.

Dann werde ich mir jetzt erstmal ne eigene Lösung schaffen. ( Ggf. auch mit Hilfe von BOT. Hab ich mir noch nie angeschaut gehabt...)
Und dann warte ich doch mal freudig auf die erste n2n-Version.
( svn read-only Zugriff auf die aktuelle Entwicklersverison wollt Ihr nicht mehr zur Verfügung stellen? )


Achja und noch ein letztes @horizont
War das jetzt mit dem iroute-Parameter ein Missverständnis, oder sollte ich mir das doch noch mal anschauen?

Ansonsten vielen Dank soweit,
bin jetzt erstmal informationstechnisch bestens versorgt ;)

Tom


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 24.04.2006 12:57 
Blowfish
Blowfish

Joined: 18.04.2005 19:31
Posts: 732
tom wrote:
[
( svn read-only Zugriff auf die aktuelle Entwicklersverison wollt Ihr nicht mehr zur Verfügung stellen? )



Doch doch, eigentlich wollte ich schon am Wochenende mit dem merge und comit fertig sein, aber ich sag nur Theorie und Praxis.

Also selbstverständlich kommt alles ins SVN, ich hab das svn in letzter Zeit ein Wenig vernachlässigt.

tom wrote:
Achja und noch ein letztes @horizont
War das jetzt mit dem iroute-Parameter ein Missverständnis, oder sollte ich mir das doch noch mal anschauen?
Tom


nein war kein Missverständniss, Du könntest die Gegenstelle als Client definieren und per iroute das das Natzwerk der Gegenseite zur Verfügung stellen.

gruß
horizont


Top
Offline Profile  
Reply with quote  
 Post subject:
PostPosted: 24.04.2006 13:20 
Tripple-DES
Tripple-DES

Joined: 15.03.2006 23:29
Posts: 11
Quote:
nein war kein Missverständniss, Du könntest die Gegenstelle als Client definieren und per iroute das das Natzwerk der Gegenseite zur Verfügung stellen.


ahhh ok
hmm ja das kommt in der Form aber momentan eher nicht in Frage....


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ]  Moderator: Moderators

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net