5
Problem mit Bird und OpenVPN - Socket error SO PRIORITY Operation not permitted
Hallo liebe Community,
da ich neu bin, hoffe ich dass der Beitrag in diese Kategorie passt.
Ich bin derzeit dabei zwei Bird Routern, die mit OpenVPN verbunden sind, OSPF beizubringen. An sich ist die ospf Konfiguration von bird absolut nichts kompliziertes und läuft, so weit ich das beurteilen kann, auch.
Auf meinem ersten Route alles kein Problem, auf dem zweiten allerdings schon.
Auf den Routern läuft folgende Software:
Router 1:
Ubuntu 17.10
bird 1.6.3
Openvpn 2.4.3
Router 2:
Ubuntu 16.04 LTS
bird 1.6.3
Openvpn 2.4.5
Auf beiden Routern existriert eine annähernd gleiche bird Konfiguration. Diese unterscheiden sich nur durch Router ID, IPs und Interface Namen. Ospf läuft auf dem ersten Router ohne Probleme, mit tcpdump sehe ich auch an beiden Enden des VPN tunnels die ospf Pakete von Router 1.
Auf dem zweiten Router bekomme ich allerdings nach dem $ birdc configure im log folgende Fehlermeldung:
Ich habe schon an Rechteprobleme gedacht. Bird läuft im User bird, openvpn ist ein daemon und wird in der Config nach nobody und nogroup verschoben. Wenn ich beide Programme als root laufen lasse ändert sich leider nichts an dem Problem.
Wenn ich ospf auf dem zweiten Router auf das lookback oder mein public Interface verlege, bekomme ich keine Fehlermeldung, das ist ja aber nun keine Lösung.
Hat dieses Problem hier schon mal jemand gehabt? Oder weiß wie ich es beheben kann?
da ich neu bin, hoffe ich dass der Beitrag in diese Kategorie passt.
Ich bin derzeit dabei zwei Bird Routern, die mit OpenVPN verbunden sind, OSPF beizubringen. An sich ist die ospf Konfiguration von bird absolut nichts kompliziertes und läuft, so weit ich das beurteilen kann, auch.
Auf meinem ersten Route alles kein Problem, auf dem zweiten allerdings schon.
Auf den Routern läuft folgende Software:
Router 1:
Ubuntu 17.10
bird 1.6.3
Openvpn 2.4.3
Router 2:
Ubuntu 16.04 LTS
bird 1.6.3
Openvpn 2.4.5
Auf beiden Routern existriert eine annähernd gleiche bird Konfiguration. Diese unterscheiden sich nur durch Router ID, IPs und Interface Namen. Ospf läuft auf dem ersten Router ohne Probleme, mit tcpdump sehe ich auch an beiden Enden des VPN tunnels die ospf Pakete von Router 1.
Auf dem zweiten Router bekomme ich allerdings nach dem $ birdc configure im log folgende Fehlermeldung:
MyOSPF: Socket error: SO_PRIORITY: Operation not permitted
MyOSPF: Cannot open socket for <interfacename>, declaring as stubIch habe schon an Rechteprobleme gedacht. Bird läuft im User bird, openvpn ist ein daemon und wird in der Config nach nobody und nogroup verschoben. Wenn ich beide Programme als root laufen lasse ändert sich leider nichts an dem Problem.
Wenn ich ospf auf dem zweiten Router auf das lookback oder mein public Interface verlege, bekomme ich keine Fehlermeldung, das ist ja aber nun keine Lösung.
Hat dieses Problem hier schon mal jemand gehabt? Oder weiß wie ich es beheben kann?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 367909
Url: https://administrator.de/contentid/367909
Printed on: April 19, 2024 at 16:04 o'clock
5 Comments
Latest comment
hoffe ich dass der Beitrag in diese Kategorie passt.
Das passt schon 
Ich habe das bis dato nur auf physischen Interfaces bzw. VLAN Interfaces konfiguriert aber noch nie auf virtuellen wie sie ja OpenVPN hat.
Hätte jetzt erstmal vermutet das es am Multicasting liegt was OSPF für die Neigbor Discovery nutzt aber wenn du die OSPF Frames mit tcpdump dort sehen kannst, dann kann es das ja nicht sein. Eine Seite sendet dann ja richtig. Eine Adjacency wird aber niemals zustandekommen wenn nur eine Seite was sendet...klar.
Auch die Tatsache das es auf der einen Maschine rennt auf der anderen aber nicht, zeigt ja das es generell vermutlich geht.
Möglich das es an der VPN Struktur liegt, denn das ist ja ein Point to Point Netzwerk. Dagegen spricht aber das eine Seite ja fehlerlos damit umgehen kann. Hast du das Interface als P2P Interface konfiguriert ?
Ein Loopback Interface zu benutzen ist in OSPF immer best Practise, denn dort kannst du /32 Hostrouten nutzen, hast eine eindeutige Router ID und der Prozess stirbt nicht solange das Loopback nicht stirbt. Es ist also nicht abhängig von irgendwelchen Link Status einzelner physischer Interfaces.
Die Fehlermeldung deutet aber eher darauf hin das irgendwas mit der OSPF Interface Konfig nicht stimmt.
So müsste es m.E. aussehen bei P2P: <code, type=plain>
area 0 {
interface "tun0" {
cost 20;
type ptmp;
hello 5; retransmit 2; wait 10; dead 60;
authentication none;
neighbors { 10.6.0.4; };
};
Dann sollte Bird sowas zeigen: <code, type=plain>
[server]# birdc show interfaces
eth0 up (index=2)
MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500
192.168.3.1/24 (Primary, scope univ)
tun0 up (index=19)
PtP Multicast AdminUp LinkUp MTU=1500
10.6.0.1/32 (Primary, opposite 10.6.0.4, scope site)
Hallo aqui,
danke für deine Antwort.
Ein Kollege hat mich vorhin (vielleicht) schon ein wenig weiter gebracht. Ich hab vergessen zu erwähnen dass es sich bei den beiden Routern um vServer handelt.
Mein Kollege meinte dass es bei OpenVZ immer wieder Probleme mit virtuellen Interfaces von VPNs gibt. Und siehe da, der zweite Router auf dem es nicht geht, ist auf Virtuozzo gehostet, also OpenVZ. Das könnte zumindest mal eine Erklärung sein. Der erste Router auf dem es geht ist LXC.
Nun ist die Frage ob es mit anderen VPN Typen geht? Hat hier jemand Erfahrung?
Ich habe vorhin mal auf die Schnelle PeerVPN getestet, da es so schön einfach ist, allerdings wollte sich mein Client einfach nicht mit dem Server verbinden. Vielleicht noch tinc oder pptp ausprobieren.
Hier meine Config für ospf:
danke für deine Antwort.
Ein Kollege hat mich vorhin (vielleicht) schon ein wenig weiter gebracht. Ich hab vergessen zu erwähnen dass es sich bei den beiden Routern um vServer handelt.
Mein Kollege meinte dass es bei OpenVZ immer wieder Probleme mit virtuellen Interfaces von VPNs gibt. Und siehe da, der zweite Router auf dem es nicht geht, ist auf Virtuozzo gehostet, also OpenVZ. Das könnte zumindest mal eine Erklärung sein. Der erste Router auf dem es geht ist LXC.
Nun ist die Frage ob es mit anderen VPN Typen geht? Hat hier jemand Erfahrung?
Ich habe vorhin mal auf die Schnelle PeerVPN getestet, da es so schön einfach ist, allerdings wollte sich mein Client einfach nicht mit dem Server verbinden. Vielleicht noch tinc oder pptp ausprobieren.
Hier meine Config für ospf:
interface "link_sd1" {
cost 5;
type pointopoint;
hello 5; retransmit 2; wait 10; dead 20;
authentication cryptographic; password "xxxx";
};$ birdc show interfaces
link_sd1 up (index=49)
PtP Multicast AdminUp LinkUp MTU=1500
10.20.30.1/32 (Primary, opposite 10.20.30.2, scope site)Ich hab vergessen zu erwähnen dass es sich bei den beiden Routern um vServer handelt.
Das spielt (vermutlich) keine Rolle denn den Anwendungen an sich ist es egal ob sie auf realem Blech laufen oder virtuell. Merken sie ja nicht Aber wie gesagt...an sich. Wenn die Basis nicht stimmt dann scheitert das da, keine Frage.bei OpenVZ immer wieder Probleme mit virtuellen Interfaces von VPNs gibt
Das wäre natürlich eine Erklärung. Also wenn da nicht wirklich alles "virtuell" ist. Ggf. hilft es den emulierten Adapter zu wechseln, das ist bei VirtualBox und Co. manchmal auch der Schlüssel zum Erfolg.Nun ist die Frage ob es mit anderen VPN Typen geht?
Im Bird Umfeld auf virtuellen Hosts mit Punkt zu Punkt Links wird sehr häufig tinc benutzt weil das sehr viel weniger Overhead hat als OVPN.Vielleicht ist das mal einen Versuch wert ?!
https://www.tinc-vpn.org
https://www.heise.de/ct/artikel/Dezentrales-VPN-mit-Tinc-785436.html
https://openvz.org/VPN_via_the_TUN/TAP_device
tinc ist jetzt aufgesetzt und funktioniert.
Allerdings bekomme ich immernoch den gleichen Fehler.
Es scheint wohl demnach nicht explizit an OpenVPN zu liegen.
Hast du zufällig auch ein Beispiel wie ich ospf über das loopback Interface laufen lasse? Wie route ich dann den ospf Traffic auf mein entsprechendes vpn Interface?
Allerdings bekomme ich immernoch den gleichen Fehler.
MyOSPF: Socket error: SO_PRIORITY: Operation not permitted
MyOSPF: Cannot open socket for link_sd1, declaring as stubEs scheint wohl demnach nicht explizit an OpenVPN zu liegen.
Hast du zufällig auch ein Beispiel wie ich ospf über das loopback Interface laufen lasse? Wie route ich dann den ospf Traffic auf mein entsprechendes vpn Interface?
Interessant ist das hier:
http://www.blissfulidiot.com/2013/10/using-bird-to-route-over-openvpn-t ...
Speziell die Aussage: "but the remote tunnel address would be unreachable. I solved this by adding a stubnet x.x.x.x/31 directive to the OSPF configuration at one of the endpoints. At the time this worked fine."
Das geht so ein bischen einher mit deiner Fehlermeldung das Bird da ja auch irgendwie von einem Stub Interface ausgeht.
Ggf. solltest du das auch mal in deinem Setup explizit definieren entsprechend mit deiner Maske.
Ansonsten mal nach bird ospf vpn googeln es gibt ne Menge Beispielkonfigs dazu speziell auch von den Freifunkern.
https://wiki.freifunk-stuttgart.net/technik:gateways:routing
usw.
http://www.blissfulidiot.com/2013/10/using-bird-to-route-over-openvpn-t ...
Speziell die Aussage: "but the remote tunnel address would be unreachable. I solved this by adding a stubnet x.x.x.x/31 directive to the OSPF configuration at one of the endpoints. At the time this worked fine."
Das geht so ein bischen einher mit deiner Fehlermeldung das Bird da ja auch irgendwie von einem Stub Interface ausgeht.
Ggf. solltest du das auch mal in deinem Setup explizit definieren entsprechend mit deiner Maske.
Ansonsten mal nach bird ospf vpn googeln es gibt ne Menge Beispielkonfigs dazu speziell auch von den Freifunkern.
https://wiki.freifunk-stuttgart.net/technik:gateways:routing
usw.
