Re: OpenVPN Problemchen

Peter Ross wrote:
> Dejan Grujin wrote:
> > Jetzt komme ich aber zu dem eigentlichen Knackpunkt bei der Sache: Die
> > Tunnel sollen NUR aufgebaut werden, wenn auch entsprechende Anfragen an das
> > jeweilige Netz stattfinden. Natürlich automatisch und nicht per Hand.
> >
> > Soll heissen, wenn ich zum Beispiel aus Netz B ein ping mache nach Netz A
> > soll erst DANN der Tunnel aufgebaut werden.
> ..
> > Sinn liegt auf der Hand, Bandbreite halten bzw nicht zu sehr einschränken
> > durch das VPN.
>
> Das VPN "frißt" kaum Bandbreite, so daß ich die Begründung nicht
> nachvollziehen kann.

Ich muss Peter recht geben. Wenn der Tunnel idle ist, gehen
da auch keine Pakete drüber (außer sporadische Keep-Alive-
Pakete, wenn Keep-Alive eingeschaltet ist und Du über TCP
tunnelst, was ohnehin nicht empfehlenswert ist, aber selbst
das ist verschwindend wenig); d.h. für die Bandbreite ist es
völlig egal, ob der Tunnel schon da ist oder nicht.

Im Gegenteil: Wenn Du den Tunnel immer nur bei Bedarf auf-
baust, hast Du durch den häufigen Auf- und Abbau insgesamt
mehr Overhead, als wenn Du den Tunnel dauerhaft bestehen
lässt.

Falls Du dennoch daran festhalten möchtest: Eine fertige
Lösung dafür ist mir nicht bekannt. OpenVPN hat so eine
Funktion nicht eingebaut, soviel ich weiß (da es, wie oben
beschrieben, eigentlich keinen Bedarf dafür gibt). Man
müsste einen Daemon laufen lassen, der irgendwie merkt,
wenn Pakete ins VPN gehen sollen (z.B. per bpf(4) oder mit
Hilfe von Firewall-Regeln, etwa per ipl(4) oder pflog(4),
oder indem der Daemon sich per Divert-Socket in ipfw ein-
klinkt), und der dann den Verbindungsaufbau veranlasst.
Problem dabei ist natürlich, dass mindestens das erste
Paket dann schonmal verloren ist (der Daemon könnte es
erneut einspeisen, was aber auch gewisse Probleme bringt).
Außerdem müsste der Daemon dann irgendwann den Tunnel
wieder abbauen, was anhand von timeouts und State-Tables
gemacht werden müsste, was auch seine Tücken hat.

Natürlich gibt es Software mit Dial-on-Demand-Funktionen,
z.B. der ppp(8) und die meisten anderen Dial-up-Programme
können das. Da ergibt es dann Sinn, wenn man bei einer
zeitbasierten Abrechnung die Kosten niedrig halten möchte.
Dagegen treibt bei volumenbasierter Abrechnung Dial-on-
Demand die Kosten eher in die Höhe!

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"I have stopped reading Stephen King novels.
Now I just read C code instead."
        -- Richard A. O'Keefe
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message