Hard coded IP als Fallback falls (m)DNS nicht möglicht ist?

Piktogramm

Fleet Admiral
Registriert
Okt. 2008
Beiträge
10.150
Meine System Alice mag Bob. Bob ist normalerweise unter bob.local via mDNS ausfindig zu machen. Manchmal ist Alice jedoch in der Welt unterwegs und das Auflösen via mDNS ist schier unmöglich. Alice und Bob kennen jedoch Christine (public Server im Web). Christine bietet ein Wireguardinterface an, über die sich alle drei über fixe IPs erreichen können. Wireguard lässt jedoch keine Broadcasts zwischen Peers durch und unterbietet damit mDNS.

Ich hätte nun gern folgendes gebaut:
Alice will Daten mit Bob austauschen und probiert bob.local aufzulösen. Sollte bob.local nicht auffindbar sein, dann (nur dann) soll Alice intern bob-local mit fe80::2%wg0 auflösen (wg0 ist das wireguardinterface von Alice welches zu Christine verbindet)[1]. Mit dem Effekt, dass der einzig bekannte Pfad zu fe80::2 über den VPN Tunnel zu Christine geht.

Die Lösung sollte für Ubuntu 20.04 brauchbar sein, das Auflösen via (m)DNS übernimmt normalerweise resolved. mDNS zu Beantworten wird derzeit über avahi erledigt (Alice & Bob), aber eigentlich will ich das beim nächsten verregneten Wochenende auf mDNS via networkd umstellen.
Lösungsvorschläge sollten DualStack fähig sein.

Ansätze die bekannt sind, die ich aber nicht mag:
  • Multiple Interfaces auf Christine zwischen denen dann Forwarding betrieben wird, welches Broadcasts einschließt (die Familie soll größer werden und irgendwann wird es fummelig..).
  • DNS Server auf Christine der .local auflöst (Alice treibt sich in der Welt rum und je nach DNS Config des Netzwerks in dem Alice ist, wird das abenteuerlich..). Zudem es "spannend" wird Christines .local-DNS zusammen mit mDNS von beliebigen anderen Netzwerken zu kombinieren.
  • Hardcoded IPs in der Hostfile (Bob hat sowieso keine lokale fixe IP, nur die IP im VPN ist fix und das auch nur, weil wireguard 0Conf blockiert...)

[1] Für den ersten Schritt vielleicht fe80::2 ohne Angabe des Interface, Interfaceangaben vertragen viele Anwendungen ja nicht :/
 
Was ist mit dem Lösungsansatz verschiedene Network-Manager Profile zu benutzen ?
Die meisten Distributionen bzw. Desktops nutzen per Default diesen - ansonsten gibt es auch ein Kommandozeilentool.
1 Roaming Profil, 1 "Home" Profil - mit den unterschiedlichen Präferenzen dann in die Pre/Post/Skripte eintragen

Der Lösungsansatz mit den IPs verändern ist etwas seltsam.
"Normal" würde doch der Service eine oder mehrere IPs haben unter denen er erreichbar ist.
Diese IPs können verschiedene Routen mit verschiedene Metriken (Interface / Link-Eigenschaften) besitzen.
Wenn sich der Ort / Verbindung ändert, dann ändern sich die Metriken - die wg0 metrik bleibt "gleich".
Also ip route <zielip> dev <wg0> ....metric 100
ip route <zielip> dev <localgateway> .... metric 10
fällt localgateway route weg, dann geht es über die schlechtere metric100


Das mit .local auflösen obwohl kein mDNS verfügbar und keine Hardcoded IPs ....
Die nsswitch.conf bietet doch dann quasi alle anderen Lösungen/Fallbacks wenn mDNS nicht verfügbar ist an.
Es gibt zwar diverse Plugins dafür, aber das nicht so richtig was du suchst. ( systemd plugin, libvirt plugin zb)

Es gibt noch verschiedene Routingprotokolle (= zusätzliche Services, die du anscheinend auch nicht so richtig willst), in Mesh-Netzwerken, die dann wissen, wie die aktuelle Topologie aussieht und wie der Client erreichbar ist - also ob zB lokal oder über wg0 - weil die Metrik der Route anders ist
Freifunk macht Mesh auf Layer 2 (pdf) und darauf läuft dann auch avahi. Freifunk läuft jedenfalls relativ problemlos mit vielen Nodes.
Dabei ist dir aber der Administrationsaufwand (Punkt 1) zu groß ?
 
  • Gefällt mir
Reaktionen: Piktogramm
Danke für die Ideen! Betriebsblindheit ftw :D

und richtig, ich habe keine Muse die Adminstration ausarten zu lassen. Die Lösung ist sowieso allenfalls temporär.
 
Zurück
Oben