OpenVPN-Paket

Hallo,


Mit dem Ping-Befehl sende ich ein Datenpaket bestimmter Größe im Ethernet (Layer2) zu einem Partner und der sollte mir das ganze möglichst zurücksenden...
Zum einen laufen Ping Pakete nicht auf Layer 2, sondern ICMP ist ein Protokoll oberhalb von IP (das liegt auf Layer 3).

Mal kurz gerechnet: 203 kBit/s * 1024 = 207.872 Bit/s : 8 = 25.984 Byte/s : 1024 = 25,37 kByte/s.
Nochmal für den Standort A gerechnet: 1.072 * 1024 = 1.097.728 Bit/s : 8 = 137.216 Byte/s : 1024 = 134 kByte/s
In deiner Rechnung sind einige Fehler drin. So rechnest du auf Basis der ATM Datenrate und dann lässt du den IP- und PPPOE-Protokolloverhead völlig aus dem Rennen.
Die Nutzdatenrate beträgt an deinem Anschluss nur 48/53 der ATM Datenrate (eine ATM Zelle hat 48 Byte Nutzdaten bei 53 Byte Länge). Im Mittel 20% der Nutzdatenrate kannst du dann noch mal für den übrigen Protokolloverhead veranschlagen, das schwankt stark mit der Paketgröße und der Fragmentierung.

Die Leitung wird bis zur Grenze ausgereizt.... die Antwortzeiten steigen. Irgendwann fehlt ein Paket, die Antwortzeit ist gesunken.
Danach steigt die Antwortzeit wieder, bis wieder ein Paket fehlt usw....
Da du mit deiner Paketgröße die maximale Übertragungsrate der Verbindung überschreitest, wird die Leitung überlastet und es kommt bei ungesicherten Paketen (wie ICMP) früher oder später zu Verlusten.

Bei einer zeitlichen Verzögerung von ca. 9 Sekunden, einer Paketgröße von
23.385 Bytes und einem Ping pro Sekunde, muss ja irgendwer 210.465 Bytes zwischenspeichern.
Die befinden sich in irgendwelchen Queues in den Routern der Internetprovider.

Wenn ich jetzt noch TCP/IP-Traffic verursache bricht die Verbindung ab... d.h. die Box am Standort B stürzt ab.
Die Box sollte davon nicht abstürzen. Das sollte die Box locker verpacken können.
 
In deiner Rechnung sind einige Fehler drin.
... und noch ein paar Dinge, di zu bedenken sind:

- Jede Verbindung hat eine MTU (maximale Größe der Pakete), allein dein Ethernet begrenzt dich auf 1500 Bytes. Alle Pakete müssen also schon dafür "zerteilt" (fragmentiert) werden (hatte Frank schon angedeutet). Jedes Paket bekommt dann wieder einen Header
- Die VPN-Verbindung hat eine geringere MTU (wegen des VPN Overheads), dafür müssen schon "normale" Ethernet Pakete fragmentiert werden.

Dein "Testszenario" mit riesigen ICMP-Paketen könnte somit aus meiner Sicht übrigens tatsächlich die Box zum Abstürzen bringen, einfach weil sie zuwenig Speicher hat um die ganze "de-fragmentierung", also das Aus- und wieder Zusammenpacken des ursprünglichen Paketes zu erledigen (allein schon OpenVPN benötigt ja einiges an Speicher).
Da du mit deiner Paketgröße die maximale Übertragungsrate der Verbindung überschreitest, wird die Leitung überlastet und es kommt bei ungesicherten Paketen (wie ICMP) früher oder später zu Verlusten.
Ein gewisses Problem ist, dass das für den Router so nicht sichtbar ist. Für den ist der "eigentliche Traffic" UDP oder sogar TCP, weil er die "eingepackten" ICMP-Pakete rausgibt.

Insgesamt denke ich, dass ein Abbruch bei deinem Test "nicht zu ungewöhnlich" ist. Im "Normalbetrieb" sollte das aber eigentlich nicht passieren...

Jörg
 
In deiner Rechnung sind einige Fehler drin. So rechnest du auf Basis der ATM Datenrate und dann lässt du den IP- und PPPOE-Protokolloverhead völlig aus dem Rennen.
Okay, ist eigentlich logisch....
Die Nutzdatenrate beträgt an deinem Anschluss nur 48/53 der ATM Datenrate (eine ATM Zelle hat 48 Byte Nutzdaten bei 53 Byte Länge).
Die Nutzdatenrate habe ich doch herangezogen, oder ist das noch etwas anderes?
Code:
 	 	Empfangsrichtung  	Senderichtung
Leitungskapazität 	kBit/s 	8160 	1276
ATM-Datenrate 	kBit/s 	2304 	224
Nutz-Datenrate 	kBit/s 	2087 	203
Nach deiner Angabe komme ich auch bei 224*48/53= 203.

Im Mittel 20% der Nutzdatenrate kannst du dann noch mal für den übrigen Protokolloverhead veranschlagen, das schwankt stark mit der Paketgröße und der Fragmentierung.
Verstanden.
Die befinden sich in irgendwelchen Queues in den Routern der Internetprovider.
Nich verstanden, stecken die nicht noch in meiner Box am Standort B, wg. ADSL?
Die Box sollte davon nicht abstürzen. Das sollte die Box locker verpacken können.
Wenn Sie doch noch in Box stecke könnte doch irgendwann der Speicher aus gehen... und soviel ist da eh nicht mehr frei....
Code:
/var/mod/root $ cat /proc/meminfo
MemTotal:        14124 kB
MemFree:           692 kB
Buffers:           328 kB
Cached:           2732 kB
SwapCached:          0 kB
Active:           6692 kB
Inactive:         1148 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        14124 kB
LowFree:           692 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
Mapped:           6140 kB
Slab:             3656 kB
CommitLimit:      7060 kB
Committed_AS:    14120 kB
PageTables:        280 kB
VmallocTotal:  1048560 kB
VmallocUsed:      1492 kB
VmallocChunk:  1045732 kB
Dein "Testszenario" mit riesigen ICMP-Paketen könnte somit aus meiner Sicht übrigens tatsächlich die Box zum Abstürzen bringen, einfach weil sie zuwenig Speicher hat um die ganze "de-fragmentierung", also das Aus- und wieder Zusammenpacken des ursprünglichen Paketes zu erledigen (allein schon OpenVPN benötigt ja einiges an Speicher).
Wie wirkt sich denn jetzt ein shaper aus?
Kann ich damit den "Zwischenspeicher" von OpenVPN begrenzen?
"Weiß" OpenVPN dann, dass gar nicht mehr Daten über die Leitung gehen und verwirft sie sofort beim Eintreffen?
Was wäre dann ein sinnvoller Wert?
Mal kurz wieder gerechnet: 203 kBit/s * 1024 = (207.872 Bit/s : 8) * 80% = 20.787 Byte/s : 1024 = 20,3 kByte/s.
Mit ein bißchen Reserve 19000 ?
 
Wie wirkt sich denn jetzt ein shaper aus?
Wie der genau realisiert ist, weiß ich nicht. Letztlich versucht er, eine maximale Datenrate einzuhalten.

Mit dem Speicher hat das erstmal nichts direkt zu tun.
Aber wie gesagt, ich denke nicht, dass im "normalen" Betrieb die Box zum Absturz kommen sollte (langsam kann es natürlich schon werden), denn im Normalfall wird ein Großteil des Verkehrs über TCP laufen, was speziell in der Lage sein sollte, ein Problem mit der MTU-Größe zu verhindern (MTU Path Discovery).

Jörg
 
Bei einer zeitlichen Verzögerung von ca. 9 Sekunden, einer Paketgröße von
23.385 Bytes und einem Ping pro Sekunde, muss ja irgendwer 210.465 Bytes zwischenspeichern.

Diese werden vom sendenden Router zwischengespeichert, der sitzt ja genau vor dem Flaschenhals.
210kB sind aber nicht so viel, daß davon der Speicher der Box voll werden sollte. Es kann aber sein, daß AVMs Firewall/NAT System damit durcheinander kommt.
 
push "redirect-gateway"

Hi,

habe meine FBF 7170 29.04.49 mit Freetz Pre16 gemoddet und bin vom ds-mod openvpn quasi fast restlos begeistert:

- Port 1194 steht schon in der ar7.cfg
- openvpn über TCP funktioniert! (Yeah Proxy!!)
- Bridging funzt super (wenn man Tap0 noch in die ar7.cfg einträgt)
- ...

Dank erst mal an alle Entwickler - SUPER Arbeit...

Hier noch eine kleine Anmerkung, die mir als Laien das Leben einfacher gemacht hätte:

- Bitte in das HOWTO/Wiki nachtragen, wie der Port in der ar7.cfg zu ändern ist, wenn er in der openvpn-gui geändert wurde (ich weiß, das wird an vielen Stellen beschrieben, gehört aber meiner Meinung nach genau dort rein) + REBOOT (das hab ich doch ein paar mal vergessen, weil es in der Wiki nicht steht

- Bitte in das HOWTO/Wiki nachtragen, dass wenn Bridging verwendet werden soll Tap0 mit in die brinterfaces in der ar7.cfg eingetragen werden muß, da es sich sonst nur um einen Tunnel handelt + REBOOT


Kann man diese Schritte in die GUI implementieren, evtl mit Hinweis darauf, daß die Box dann neu gestartet werden muß? Oder aber vieleicht eine andere Methode (evtl. virtual Device) einsetzen, die diese Schritte übernimmt?

Zum Schluß noch eine technische Frage:

Die Gui gestattet es jetzt ja, clientspezifisch Routen anzugeben. Für mich wäre die extreme Form interessant -> Clientspezifisch den Traffic umzuleiten ala

client-config-dir /var/tmp/clients_openvpn/

und dann in der /var/tmp/clients_openvpn/Client01
push "redirect gateway"

wie krieg ich das hin?

Gruß

Tom
 
Hi und willkommen Tom,

schön, wenn es dir gefällt ;-)

- Bitte in das HOWTO/Wiki nachtragen....
Das Wiki lebt von allen. Jeder Forums-Nutzer kann sich dort "nützlich machen" ;-) Soll heißen: Ergänzungen Korrekturen und Verbesserungen kannst du dort auch selbst einpflegen...

Kann man diese Schritte in die GUI implementieren, evtl mit Hinweis darauf, daß die Box dann neu gestartet werden muß? Oder aber vieleicht eine andere Methode (evtl. virtual Device) einsetzen, die diese Schritte übernimmt?
Hatte ich mal angedacht. Aber gerade die "neusten Entwicklungen" (eine GUI für die AVM-Firewall und die Möglichkeit, mit einem "Mini-Patch" die Portfreigabe auch in der normalen AVM-GUI zu erledigen machen das meiner Ansicht nach überflüssig (wird ja nur einmal gebraucht, und wenn es im Wiki dann noch klarer wird ;-))

Für mich wäre die extreme Form interessant -> Clientspezifisch den Traffic umzuleiten
Mit der GUI wohl nicht. Aber man kann ja die Client-Dateien im CCD verändern, was ohne Neustart des VPN beim nächsten Connect wirkt, wenn ich mich recht entsinne...
Ich denke, das wäre dann doch zu speziell, dies noch in die GUI zu bringen, das ist schon eine echte "Experten-Config" und die Experten müssen ja noch einiges "zu Fuß" tun können ;-)...
Wenn dir natürlich eine geniale Idee zur "einfachen" Umsetzung kommt: Den Code hast du ja und Unterstützer sind immer willkommen!

Jörg

EDIT Den Part mit dem ar7cfgchanged und den Hinweis auf die "neue Portforwarding-Entwicklung" habe ich mal aufgenommen, wenn du vielleicht den Bridging Part ergänzen möchtest?!?
 
Zuletzt bearbeitet:
Ich wollte auch noch sagen, dass ich echt total begeistert bin von der neuen GUI!!

@tommatt
der Ordner und die Files werden ja schon erstellt für die Individuelle Config, bei mir für ne feste IP.
hier hat jemand davon erzählt, dass er ein up bzw down script mit den parametern starten konnte.
Du könntest duch ein fach ein script schreiben, was die gewünschte client funktion noch hinzufügt, ala
Code:
echo "push \"redirect gateway\"" >> /var/tmp/clients_openvpn/Client01
...(halt die optionen für jeden cleint dran hängen)

Sollte das ncith gehen??

Hab mal die Befehle, die man verwenden könnte, von meiner VM kopiert:
Code:
--up cmd        : Shell cmd to execute after successful tun device open.
                  Execute as: cmd tun/tap-dev tun-mtu link-mtu \
                              ifconfig-local-ip ifconfig-remote-ip
                  (pre --user or --group UID/GID change)
--up-delay      : Delay tun/tap open and possible --up script execution
                  until after TCP/UDP connection establishment with peer.
--down cmd      : Shell cmd to run after tun device close.
                  (post --user/--group UID/GID change and/or --chroot)
                  (script parameters are same as --up option)
--down-pre      : Call --down cmd/script before TUN/TAP close.
--up-restart    : Run up/down scripts for all restarts including those
                  caused by --ping-restart or SIGUSR1
 
Zuletzt bearbeitet:
Wiki/howto

Hallo,

ich habe mal die WIKI ergänzt, speziell den Teil Bridging...

An der ein oder anderen Stelle habe ich noch etwas hinzugefügt, was aus meiner Sicht fehlte, um einen VPN-Server in einem Rutsch auf der Box zum Laufen zu bringen...

Gruß

Tom
 
Hi,

noch ein paar kleine Fragen:

Unterstützt die aktuelle OpenVPN Version (2.1_RC in Freetz 2040 für FPF 7270) die Option "--port-share" und kann ich diese in den Experteneinstellungen eintragen?

Wozu dient der Package-Eintrag (in menuconfig) Enable Management Console? Schließt dieser einen zusätzlichen Eintrag "--management IP port [pw-file]" in den Experteneinstellungen aus?

Kann es sein, dass es in der Firmware .55 mit OpenVPN (TCP-Server auf Port 443 eingetragen in ar7.cfg) zu Problemen mit der AVM Fernwartung kommt?

Danke und Gruß

Tom


PS: Zu meinem Problem mit "redirect-gateway" ein paar Posts weiter oben... Das funktioniert auch hervorragend, wenn man folgende Zeilen in die Client-Config einträgt:

Code:
pull
redirect-gateway
 
Zuletzt bearbeitet:
Hi,

zum port-share: Versuch macht kluch ;-), es sollte mit kompiliert sein, dem Eintrag in den Experteneinstellungen steht also nichts im Wege.

Die menuconfig Option entspricht beim Compilieren dem "--enable-management" (siehe hier) ohne die Option geht "management <IP> <port>" nicht (Die Optionen kommen in die Config, daher immer ohne "--" am Anfang).

Zum Punkt "Fernwartung" kann ich nichts sagen (habe keine 7170), aber wenn die wie ich mich zu erinnern meine auf https basiert(ebenfalls Port 443), kann das sehr wohl sein...

Jörg
 
OpenLDAP Client Tools

Hi,

ich würde ganz gerne die VPN Authorisierung an meinem PDC vornehmen. Hat hier schon mal einer was gelesen, gehört, wie ich die ldap client tools auf die Box bekomme um ein Authorisierungsscript ala:

ldapwhoami -x -h X.X.X.X -D uid=$username,ou=UserObjects,dc=werweissdasschon,dc=nu -w $password

laufen lassen zu können?

Gruss

Tom
 
Du solltest so etwas nicht im OpenVPN Thread posten, da es hier absolut nicht passt.

LDAP != VPN

wengi
 
[Edit frank_m24: Sinnfreies Fullquote vom Beitrag direkt darüber gelöscht. Lies noch mal die Forumregeln.]

Sehe ich ein wenig anders, ist schließlich eine Frage der OpenVPN-Berechtigung - aber wie Du willst...
 
wie ich die ldap client tools auf die Box bekomme
Im Prinzip fehlen die LDAP Client Tools, die müssten halt noch für die Fritz!Box kompiliert werden.
Informier' Dich, wie man mit der freetz Toolchain eigene Programme kompiliert. Informationen dazu findest Du reichlich in Forum und Wiki.
Idealer Weise setzt Du das ganze gleich als mk Datei im freetz Format um. So kann Deine Arbeit dann einfach ins freetz integriert werden.

Du solltest so etwas nicht ... posten, da es hier absolut nicht passt.
Wenn Du nicht verstehst, was gemeint ist, dann halte Dich doch einfach zurück.
 
Wenn Du nicht verstehst, was gemeint ist, dann halte Dich doch einfach zurück.

<offtopic>
ich verstehe, was gemeint ist. Ich betreibe selbst LDAP Clients und Server...
Es geht allerdings um die ldap client tools, die ja auch komplett unabhängig von VPN eingesetzt werden können.

Ich habe ihm empfohlen einen eigenen Thread aufzumachen, da sicherlich nicht so viele Leute diesen Thread verfolgen und die Erfolgsaussichten auf eine Antwort in einem eigenen Thread wohl höher sind.

Aber ich werde jetzt einfach mal machen, was Du sagst und halte mich zurück.
</offtopic>
 
Hallo,

könnt Ihr mir bitte auf die Sprünge helfen, wie ich vorgehen muss, um OpenVPN auf meiner FB 7170 mit meinem Macbook testen zu können?

fritz.box: 192.168.178.11 (255.255.255.0)
mb: 192.168.178.8 (255.255.255.0)

Ich möchte OpenVPN erst einmal als Server auf der FB laufen lassen.
Damit kann ich doch auf die FB remote zugreifen, richtig?

Im OpenVPN.net HOWTO verstehe ich leider nur Bahnhof, so dass mir die OpenVPN-Einstellungen im Freetz-WebGUI unverständlich sind.

Kann man überhaupt ein VPN zur FB aufbauen, wenn man im selben lokalen Netzt sitzt?
Oder muss ich das von außerhalb testen? Aber wie soll ich das machen?

.
 
Zuletzt bearbeitet:
Hallo,

Oder muss ich das von außerhalb testen? Aber wie soll ich das machen?
Blöde Frage: Wenn du keinen Zugang von außen realisieren kannst, warum benötigst du dann OpenVPN für die Fernwartung?

Die wirkliche Funktionalität kann man nur von außen testen. Dennoch kann man auch von innen VPN Verbindungen aufbauen - nur vernünftig testen kann man sie nicht.

Um auf die FB aus der Ferne zugreifen zu können, gibt es ja mittlerweile auch https oder man kann SSH verwenden. Nur dafür ist OpenVPN eindeutig oversized.

Ansonsten: Bessere Anleitungen, als die Howtos hier im Wiki oder direkt bei OpenVPN, wird dir niemand geben können. Und sie per Copy & Paste hier rein zu kopieren, macht wohl auch keinen Sinn.

Falls du dann zu einzelnen Punkten Detailfragen hast, kannst du dich ja hier melden. Aber den Anfang solltest du schon selber machen.
 
Neben dem Wiki kannst du ja vielleicht auch nochmal in das hier angegehängte Dokument schauen. Obs dir "besser" gefällt/hilft, weiß ich natürlich nicht...

Jörg
 
Tja, ich blicke es leider überhaupt nicht. :confused:
Nun habe ich mir die HowTos und auch das angehängte PDF (danke dafür!) durchgelesen, aber ich habe immer noch keinen Plan, wie das alles zusammenhängt. Ich bin ja wirklich kein Linux-Neuling, aber mit dem VPN-Kram habe ich so meine Probleme.
Natürlich möchte ich das gerne erst einmal von zu Hause alles einrichten, und dafür muss ich es ja auch erst einmal lokal testen. Wenn das soweit läuft (was auch immer das heißt), dann könnte ich es von remote versuchen.

Aber vielleicht ist (Open)VPN für meine Zwecke auch das Falsche?
Ich möchte einfach nur von unterwegs (Macbook) auf meine FB gesichert zugreifen können (ssh), Zugriff auf mein NAS dahinter (FTP UL/DL) und später ggf. auch gesicherte VNC-Verbindungen zw. Macbook und meinem alten PC (XP) zu Hause hinter der FB herstellen können.
Ist VPN dafür nicht gedacht?
 

Statistik des Forums

Themen
246,067
Beiträge
2,245,473
Mitglieder
373,504
Neuestes Mitglied
andkel
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.