Re: Wohin mit dem OpenVPN Server?

Stefan Sander wrote:
wir wollen in unserer Firma für unsere Roadwarrior eine OpenVPN
Bridge in unser lokales Netzwerk einrichten. Vom Prinzip sollen
also die User nicht merken ob sie direkt im Büro sind oder irgendwo
in der schönen weiten Welt, daher dachte ich an die bridging Variante
wegen der Broadcasts (Microsoft Serverfarm vorhanden...).

Meine Frage nun, wohin stelle sicherheits- und performancetechnisch
die Box?

Variante 1: DMZ
Ich geb dem Server eine öffentliche IP und setze ihn in die DMZ,
da stellt sich mit nur die Frage ob das Sinn macht, generell ist
DMZ ja gut, aber dann würden ja alle Clients mit einer lokalen
Adresse über die Firewall von der DMZ aus ins LAN verbinden...

Wer sagt, daß man nur eine DMZ haben kann?

Es wäre extrem sinnig, das Ding auf einem eigenen Interface zu haben. Ob
das jetzt das virtuelle direkt auf der Firewall ist, oder das physische
von der Firewall zur VPN-Box ist Geschmackssache.


Bei Bridging will man _das Ergebnis_ nach dem Auspacken des
VPN-Datenstromes definitiv _nicht_ zusammen mit irgendwelchem
unsicherem Kram in einem physischen Netz haben.

Wie willst Du das wieder auseinanderkriegen?

Du kannst ja nicht definitiv sagen, wer ein Paket auf ein unsicheres
Netz geschoben hat.


Du kannst natürlich Das Ding mit einem Bein in die DMZ, mit einem
anderen ins LAN klatschen. Hat aber IMHO keinen Vorteil gegenüber
einer Forwarding-Lösung Richtung LAN.


Also entweder das Ding kriegt firewallseitig seine eigene Netzwerkkarte
und die trägt dann ge- und entkapselten Traffic und wird passend
gebridget (eklig, Du mußt ja den gekapselten Traffic routen und den Rest
bridgen), oder man verpaßt dem VPN-Server 2 Netzkarten:

Eine Richtung Firewall/DMZ-Netz und eine Richtung LAN.


Variante 2: Auf die Firewall
...haben mir jetzt mehrere geraten, aber meine derzeit
nur von innen mit ssh erreichbare variante des Linux
Paketfilters (also von aussen komplett dicht) wäre mir
deutlich lieber...

Das ist IMHO ziemlich schnurz. Ein kompromittierter VPN-Server
unterscheidet sich vom Grad der Katastrophe her nur extrem minimal
von einer (wegen darauf laufendem VPN-Server) kompromittierten Firewall.

Beides bedeutet Vollzugriff auf's LAN.

Der Unterschied ist nur noch, daß man ggf. nicht gleich auch die
Firewallpolicy abschalten kann.

Untertunneln tut man sie bereits. Schließlich hat man vollen LAN-Zugang
und was man auf der anderen Seite mit seinem Internetzugang macht
ist ja dann die eigene Sache.

Der Unterschied kommt ggf. zum Tragen, wenn die Firewall _mehrere_
interne Netze bedient und nur weniger kritische davon VPN-Zugang haben.


Dann kann es schon sehr relevant sein, ob jetzt ein Teilnetz offen ist,
oder gleich alles.


zudem hat der ja von aussen eine öffentliche Adresse, da bin ich mit
nicht sicher ob das mit dem bridging hinhaut.

Besonders dann haut es hin. Das VPN-Interface wird mit dem LAN-Interface
gebrückt. Wenn Du das außerhalb des LANs machst (z.B. in eigener "DMZ"),
mußt Du eh das, was aus dem VPN-Interface rauskommt, wieder ins LAN
brücken. Deshalb ist auch die DMZ-Lösung ohne zweites Interface nicht
gerade Klasse - siehe oben.


Variante 3: In LAN + redirect
Als letzte Variante könnte ich mir vorstellen, man stellt
ihn einfach direkt ins LAN mit privater IP und leitet VPN-Anfragen
vom Paketfilter/Router aus an die box weiter.
Klingt irgendwie wieder unsicher so direkt von aussen auf den
VPN Port eines internen Servers...

Wenn der VPN-Server auf ist, hast Du Vollzugriff auf das LAN. Punkt.
Egal wo der steht. Denn das ist seine Aufgabe: Vollzugriff auf das LAN
zu gewähren.


Also Zusammenfassung:

Einfachste Lösung: Auf die Firewall.
Nicht zu empfehlen, wenn die mehrere Sicherheitszonen betreut, von denen
nur eine eher nachrangige den VPN-Zugang braucht.

Nächsteinfachere Lösung: Forwarding auf einen LAN-Server. Nachteil: Man
kann Zeug, das für die Firewall vie VPN-Traffic ausieht ins LAN
injecten. Normal kein Problem, wenn man nicht extrem kaputte Dinge im
LAN hat, die dann ggf. Husten kriegen.

Nächste: VPN-Server in DMZ, 2. Interface zum LAN.
Ist fast wie eben, nur daß halt in der DMZ niemand Husten kriegen darf.

Nächste: Dasselbe mit explizitem Interface nur für den VPN-Server.
Dann kann kein Fremder mehr Husten kriegen. Und wenn der VPN-Server
selber kotzt, dann tut er das in allen Fällen.

Absehen würde ich von einer Konstruktion in der Art von VPN-Server in
DMZ und das DMZ-Interface teilweise mit dem LAN verbrücken. Das geht
garantiert schief.


2. Frage
Welche Hardware empfiehlt sich für OpenVPN und Paketfilter
wenn ca. 20 Mitarbeiter täglich von aussen zugreifen
und nochmal ca. 30 von innen?

Wieso greifen die internen auch via OpenVPN zu? WLAN?

Wie *** ist die Leitung? (innen/außen)

"normale" Serverhardware (also ein beliebiger 19"-Eimer der unteren
Preisklasse) hat IIRC was um die 45MBit/s gepackt, als ich das letzte
mal gemessen habe. Wenn die Gesamtbandbreite kleiner ist, brauchst Du
nix wildes.

Nimm aber nicht gerade einen fanless-400MHz-Net-Appliance-Ziegel. Das
wird knapp, wenn des mehr als einige MBit nach draußen hat. Für ein
DSL 2000 geht aber auch der prima - wie man gerade live sieht.


CU, Andy
.