VPN/Tunnelserver

[tuxmos]

Die VPN-Tunnel gehen nicht. Müssen die eventuell auch mal umgestellt werden?

René

[Cyrus]

Was geht denn dort nicht?

[tuxmos]

Ich komme z.B. nicht nach Kanena durch, oder wenn ich von mir (Lessing5) ein Node in großer ETX-Entfernung aufrufe bzw. traceroute, geht die Route nur über Funk und nicht über die alternative, kürzere (ETX).
Mein Node und auch die Topo zeigt aber einen bestehenden Tunnel an.

René

[tox]

also ich komme nach kanena durch. aber das restliche problem hab ich auch: a) hab ich auch schon beobachtet, wie der router nicht die eigene vpn-verbindung benutzt hat, sondern erst mal per funk zu einem anderen mit vpn gehüpft ist.

und b) mit permanenter boshaftigkeit trennt openvpn ständig die verbindung zu dem einen server (252.193) und meint dann, dass sie noch verfügbar ist. und im moment seh ich gerade, dass der eine vpn-adapter aus irgendeinem grund (ich habs nicht eingestellt) die adresse 104.62.1.5 bekommen hat.
leider kann ich aus dem log des routers nicht sehr schlau werden, weil das olsrd mir das zugespammt hat mit der meldung: "kern.err olsrd[27963]: OLSR: sendto IPv4 No such device", bis dann cron den dämon neugestartet hat.

[Cyrus]

Letzteres liegt daran, dass ich meinen VPN-Server, von 104.61.252.193 auf 104.62.1.1 umgestellt habe, entsprechend ändern sich auch die DHCP-Bereiche für die Interfaces, ich hoffe der 252.193 fliegt bald automatisch raus, da er in Wirklichkeit nicht mehr existiert.

[tox]

brauchen wir da neue konfigurationen?

[Cyrus]

nein

[tox]

mh, die server sind nun offenbar umgestellt. die effekte lassen nicht nach. mein router musste gestern und heute jeweils schon wieder neu gestartet werden, nachdem die vpn-verbindungen flöten gegangen sind. zuerst verabschiedet sich immer die verbindung zur 1.65 und später dann auch die 1.1. eine erscheinung ist auch noch, dass man zwischenzeitlich laut topo kein hna mehr ist (wie grad bei 3dfx). dann sind irgendwann beide verbindungen weg und man taucht nicht mehr im netz auf. und die vpn-netzwerkadapter auf dem router machen sich n lenz und zeigen alles fein an, wie wenn nichts wäre...

[se]

kenn ich, dass sich vpn-verbindungen verabschieden. dachte das liegt daran, dass die internetverbindung ausgelastet ist und die udp-pakete von openvpn nicht durchkommen und somit ein timeout passiert. könnte man mal an der config rumtunen. dass du aus der topo rausfliegst, wenn deine vpn-verbindung weg ist, ist ja ganz klar. das ist wie wenn ne funkstrecke einreißt.

[3dfxatwork]

Ja das Problem hab ich im Normalfall auch, wenn meine Leitung nicht ausgelastet ist, z.Z. kann es wirklich daran liegen, zumal mein Router meine Pakete priorisiert behandelt als die die vom FF-Router kommen.
Aber vielleicht gibt es hier einen zusammenhang ? http://www.freifunk-halle.de/phpBB3/vie ... =14&t=1024
Vielleicht komm ich morgen mal dazu da bissel Ursachenforschung zu betreiben

[3dfxatwork]

Also ich komm jetzt gar nicht mehr auf die vpn server, ich weiß nicht ob cyrus was mit den Zertifikaten gemacht hat, aber dann sollte ja keiner mehr drauf sein, hier mal mein log:

Code: Alles auswählen

May 17 16:28:50 (none) kern.err openvpn[3046]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
May 17 16:28:50 (none) kern.err openvpn[3046]: TLS Error: TLS handshake failed
May 17 16:28:50 (none) kern.notice openvpn[3046]: SIGUSR1[soft,tls-error] received, process restarting
May 17 16:28:51 (none) kern.err openvpn[3044]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
May 17 16:28:51 (none) kern.err openvpn[3044]: TLS Error: TLS handshake failed
May 17 16:28:51 (none) kern.notice openvpn[3044]: SIGUSR1[soft,tls-error] received, process restarting
May 17 16:28:52 (none) kern.notice openvpn[3046]: UDPv4 link local (bound): [undef]:5002
May 17 16:28:52 (none) kern.notice openvpn[3046]: UDPv4 link remote: 78.47.163.38:5002
May 17 16:28:53 (none) kern.notice openvpn[3044]: UDPv4 link local (bound): [undef]:5001
May 17 16:28:53 (none) kern.notice openvpn[3044]: UDPv4 link remote: 88.198.51.136:5001

Das kommt ca jede Minute.
ich hab mal gegooglt und dabei das auf openvpn.net gefunden:

I'm getting this error: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

One of the most common problems in setting up OpenVPN is that the two OpenVPN daemons on either side of the connection are unable to establish a TCP or UDP connection with each other.

This is almost a result of:

* A perimeter firewall on the server's network is filtering out incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port number 1194).
* A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194. Be aware that many OSes will block incoming connections by default, unless configured otherwise.
* A NAT gateway on the server's network does not have a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server machine.
* The OpenVPN client config does not have the correct server address in its config file. The remote directive in the client config file must point to either the server itself or the public IP address of the server network's gateway.
* Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it to the "Exceptions" list) it for OpenVPN to work.

Aber das hilft nicht wirklich weiter, vielleicht ha ja noch jemand ne idee: mal noch nen Wort zu meiner Konfiguration:
Aus dem FF werden alle Pakete an das Internet weitergeleitet, da sollten also keine Pakete hängen bleiben.

[tox]

mh bei mir kommt der fehler nich..., ich bin noch verbunden... mit dem einen server... wer weiß wie lange noch...

[Cyrus]

Also ich komm jetzt gar nicht mehr auf die vpn server, ich weiß nicht ob cyrus was mit den Zertifikaten gemacht hat, aber dann sollte ja keiner mehr drauf sein, hier mal mein log:

Immer ich!

Gib mal bitte

Code: Alles auswählen

date

auf der Konsole ein und poste die Ausgabe

[3dfxatwork]

root@3dfx-ff_1:~# date
Sun May 18 16:53:32 CEST 2008

[Cyrus]

hmm ok, also zumindest schonmal kein datumsproblem...

[3dfxatwork]

Heyhey interessanterweise geht die 1.1 jetzt ich weiß zwar nicht warum, irgendwie ging mein DSL den ganzen Abend nicht, aber daran sollte es ja nicht liegen ^^

[tox]

was habt ihr gemacht, jetz hamm plötzlich alle vpn-user wieder verbindungen zu beiden konzentratoren...?

[se]

habe den olsrd neugestartet.

[3dfxatwork]

Ich nicht ich werd bekoppt (genau dein hammer stromer), mal sehen ob es ein neustart des routers bringt

[stromer]

Kommt man nichts ahnend ist Heimatreich und dann: alles geeeelb - iiiih!
Der IP-Verwaltung zufolge ist seit ca 11:15 die letzte Statusmeldung durchgekommen. Mein HNA-AP (*16.1) zeigt auch nach einem vorsichtshalber ausgeführten Neustart die Tunnelroute nicht mehr an. Funktioniert aber sonst ohne Probleme, bietet auch die Internetverbindung und die üblichen Strecken zu den anderen Kanenaer-AP.

Hat jemand am Tunnel gebuddelt? Irgendeine Lösungsmöglichkeit?

[tox]

gute frage, das. ich war auch eine zeitlang ab besagter uhrzeit weg. irgendwas ist offenbar um die drehe mit dem vpn geschehen. hab einfach meinen router neu gestartet, da gings wieder. merkwürdig, dass das bei dir nicht klappt. kannst du die ifconfig-ausgabe mal posten?

[stromer]

kannst du die ifconfig-ausgabe mal posten?

Jo, ich nehm mal an vom AP? Da ist sich und die verbundenen Nodes so eben gegen 8:00 Uhr:

ifconfig an 16_1.jpg (387.68 KiB) 18532 mal betrachtet

Nodes an 16_1.jpg (198.22 KiB) 18531 mal betrachtet

[tox]

dir fehlt offenbar die vpn-verbindung. wahrscheinlich ist sie nicht gestartet. warum das so ist, wer weiß.
zum starten gehst du nach /etc/init.d
dann tippst du ein: ./S99openvpn start , und bestätigst. im zweifel auch mal stop vorher oder restart.
dann sollte in ifconfig ein gerät namens tap0 auftauchen, da in der spalte wo jetzt vlan0/1, eth0/1 usw. stehen.

[stromer]

Schön und danke, habe ich gemacht, Ergebnis aber weiterhin negativ.
In dem Verzeichnis "etc/init.d" standen aus unerfindlichen Gründen zwei Dateien mit S99*, die S99openvpn hatte so ein komisches Zeichen wie Verknüpfung bei Windows im Symbol, habe ich umbenannt (war vielleicht falsch?).
Die Dateiliste siehe Bild:

ifconfig an 16_1 neu.jpg (413.19 KiB) 18481 mal betrachtet

In meiner uralten Datensicherung des Routers gibt es nur die "S99done". Vielleicht muss das Verzeichnis erneuert werden, bitte um entsprechende Hinweise oder noch besser ein funktionierendes Muster / Duplikat.

[tox]

ich weiß nicht, was du genau meinst mit einem zeichen wie verknüpfung bei windows im symbol. in welcher weise hast du das umbenannt? mich wundert es, dass es sich bei dir nicht um einen link handelt, aber das kann nicht durch umbenennen verursacht werden. ich denke mal, es ist schon alles richtig, da die einrichtung sicherlich etwas älter ist und von se oder cyrus vorgenommen worden war. sinnvoll wäre es, wenn du mir noch die ausgabe des kommandos "ls -la S99openvpn" posten könntest.

ausgehend davon, dass ich glaube, dass die datei fehlerfrei ist, find ich es merkwürdig, dass das vpn nach "start" nicht auftaucht, mach mal vorsichtshalber stattdessen ein "stop" und dann nochmal ein "start". wenn das nichts hilft, starten wir das script manuell und schauen nach dem fehler:
führ zunächst in dem ordner "./S99openvpn stop" aus. dann wechselst du in den ordner /etc/openvpn dort gibst du ein: "openvpn client-vpn2.conf" und bestätigst. dann sollte eine art protokoll auftauchen, dass du bitte postest. wenn sich in der ausgabe nichts mehr ändern, kannst du das programm durch einen druck auf strg+c abbrechen. dasselbe könntest du auch mit der client-vpn1.conf tun, allerdings wirst du damit keine verbindung bekommen, da der entsprechende server schon seit einiger zeit unten ist.

[3dfxatwork]

wenn die S99openvpn fehlerhaft sein sollte, kann du auch mal ./openvpn start versuchen, falls es dann funktioniert liegt es an der S99 Datei, das könntest du dann beheben indem du die s99 löscht und einen neuen link erstellst, also

Code: Alles auswählen

rm S99openvpn
ln -s openvpn S99openvon

du solltest du dabei aber im Ordner /etc/init.d befinden.

[4huf]

Ich glaube nicht das an den Dateien was geändert werden muss.
Was sagt den "logread" ?
Dort stehen die "wichtigen" Dinge drinn, z.B. warum der Tunnel nicht hoch kommt.
Außerdem wird das tap0 erst erstellt wenn der Tunnel steht und das passiert ja offenbar nicht.

mit "ps ax" konnte man noch mal sehen ob das openvpn überhaupt läuft.

[stromer]

Habe diverse Anweisungen ausgeführt:

S99open1.jpg (25.6 KiB) 18428 mal betrachtet

Und bei ps ax kommt das:

ps_ax.jpg (222.2 KiB) 18430 mal betrachtet

ls -la... ist hier:

openvpn client1.jpg (45.23 KiB) 18428 mal betrachtet

Beim logread, allerdings nachdem ich mal openvpn gestartet hatte, kommt dauernd Info "Connection refused":

logread.jpg (848.24 KiB) 18430 mal betrachtet

Für heute habe ich keine Lust mehr. 3dfxatwork war so freundlich Zertifikate für seinen vpn-server zu schicken, werde ich mich morgen mal dran machen (das System zum Absturz zu bringen ).
Wenn das auch nichts wird habt Ihr am Do. eine schöne Aufgabe, bringe ich das Dingens mit!
Schönes Restwochenende!

[tox]

S99open1.jpg

Das sieht nicht richtig aus. Die dateigröße spricht dafür, dass es sich um eine falsche datei handelt. 453 byte ist eigentlich die S99done-datei. normalerweise hat man an dieser stelle einen symbolischen link von "S99openvpn" auf "openvpn", die sich im selben ordner befindet. diese sollte 2377 byte groß sein (oder zumindest nahezu), bitte überprüfen. überprüf bitte ebenso, ob die datei "S99done" die 453 byte groß ist und fahr nur dann fort.
lösche S99openvpn durch das kommando:
rm S99openvpn
dann leg einen neuen symlink mit dem kommando an:
ln -s openvpn S99openvpn
dann führ einen neustart durch und überprüfe, ob das vpn nun geht.

Und bei ps ax kommt das:

ps_ax.jpg

openvpn ist wie vermutet nicht gestartet.

ls -la... ist hier:

openvpn client1.jpg

ups bei dir heißt die datei noch vpn1.conf. sollte das vpn nach der änderung oben immer noch nicht funktionieren, führe bitte diesen schritt mit "vpn2.conf" anstatt "client-vpn2.conf" durch.

Beim logread, allerdings nachdem ich mal openvpn gestartet hatte, kommt dauernd Info "Connection refused":

logread.jpg

Das kommt wahrscheinlich durch das vpn1, das wie schon erwähnt seit einigen monaten unten ist.

[stromer]

Moin, moin, alles "befehlsgemäß" ausgeführt. Die S99openvpn war sicherlich durch meine Umbenennung ein bischen verkehrt, das dieses kleine Posekel im Dateisymbol eine Verknüpfung darstellt weiß ich jetzt.
Aber der Erfolg hat sich trotzdem damit nicht eingestellt:

openvpn client2.jpg (71.78 KiB) 18397 mal betrachtet

Also hab ich die Installationsanweisungen von 3dfxatwork ausgeführt und siehe da Kanenea ist in der Topo wieder aufgetaucht! Hurra und Dank allen Unterstützern!
Der Tunnellink zu 104.62.1.129 wird zwar in der Topographie noch nicht angezeigt, aber was interessieren derartige Kleinigkeiten.

Edit: Mittlerweile auch den Hilfs-Reserve-Zweit-Tunnel aus Kanena zur *1.129 "gegraben", und funktioniert.