Hallo Jörg,
10.0.0.1 auf der OPNsense braucht man für das Proxy SSO?
Die resolv.conf wird ausgewertet, wenn man „Do not use the local DNS…“ deaktiviert hat, ansonsten eben nicht.
Viele Grüße
Klaus
Hallo Jörg, hallo Klaus,
in der resolv.conf auf der OPNsense stehen bei mir neben der Domain noch der localhost, die 10.0.0.1 und die 129.143.4.3 drin.
Die verschiedenen Häckchen auf der Einstellungsseite hab ich mal durchprobiert, ohne Ergebnis. Ich hab alle Server aus der Liste gelöscht, auch den 10.0.0.1, keine Änderung im Verhalten des Clients. Das „Verwende Gateway“ - „Keiner“ dahinter ist korrekt, oder?
Viele Grüße,
Stefan
Hallo Klaus, hallo Stefan,
ob der 10.0.0.1 für SSO benötigt wird, das weiß ich leider nicht. Inder Tat wäre das kein Loop, solange der Unbound als echter Resolver arbeitet. In diesem Fall schadet der Eintrag nicht.
Aus meiner Sicht ist das aber auch zweitrangig. Diese Einstellungen sind doch nur relevant, wenn ein Hostname direkt auf der Firewall aufgelöst wird.
Wenn ein Hostname auf dem Client aufgelöst wird, dann ist der Weg meines Wissens so:
Client fragt den LMN-Server
LMN-Server löst für Hosts aus dem Schulnetz auf, alles andere leitet er weiter zur OPNsense
Auf der OPNsense landet die Anfrage beim Unbound - damit spielen Einstellungen aus der resolv.conf etc. keine Rolle mehr.
Der Unbound ist bei mir als echter Resolver konfiguriert, nicht als Forwarder: Bei „Services → Unbound DNS → General“ ist der Haken bei „DNS Query Forwarding“ nicht gesetzt. Ich verstehe das so, dass dann der Unbound selbst die Anfragen rekursiv auflöst. (Und wenn man diesen Haken setzt, dann darf der LMN-Server auf der OPNsense nicht als Nameserver eingetragen sein, sonst hat man den Loop).
Es wäre nun die Frage, weshalb das nicht klappt. Mein Verdacht ist, dass es irgendwo beim Zusammenspiel von IPv4 und IPv6 klemmt.
Beste Grüße
Jörg
Hallo zusammen
Tatsächlich ist der 10.0.0.1 für SSO notwendig. Das sieht man auf der OPNsense unter:
Dienste - Web Proxy - Single Sign-On. Ohne den LMN Server gibt es da Fehler bei der Namensauflösung
Genau, z.B. für das SSO.
Ja, so ist es
Ist auch richtig und habe ich auch ausprobiert. Da wird dann kein Name mehr aufgelöst.
Weiter oben wurde schon geschrieben:
@lessi
Es kann natürlich sein, daß die OPNsense Firewallregeln hat, die ein direktes Abfragen von einem Client aus verhindern.
Logge Dich doch mal direkt auf dem Server ein und mach:
dig @10.0.0.254 ncbi.nlm.nih.gov
Dann evtl. auch die OPNsense fragen, wer der Nameserver für diesen Host ist:
dig @10.0.0.254 ncbi.nlm.nih.gov ns
Man könnte auch explizit IPv6 oder IPv6 zur Namensauflösung verwenden:
dig -6 … oder dig -4 …
Vielleicht auch mal den Unbound DNS neu starten um den Cache zu leeren.
Viele Grüße
Klaus
Edit: Ergänzungen zu IPv4/IPv6
Hallo Klaus,
Ergebnis ändert sich nicht, außer dass statt dem A ein NS dasteht. Aber beidesmal keine Adressen dabei.
Gleiches Ergebnis.
Will ich während des Unterrichts gerade lieber nicht tun (jede Menge Streaming…), habe den ganzen Server seit November aber schon ein paarmal neu gestartet…
Aber warum sollten dann alle Webseiten funktionieren - auch welche auf Google Fundstelle 153, die garantiert niemand in der Schule außer mir angeklickt hat - nur die NCBI-Seite nicht. Und in der Forewall stehen eigentlich nur IP-basierte Regeln - und er bekommt ja die IP dieser URL gar nicht geliefert, daran kann es also auch nicht scheitern.
Zu der IPv6-Sache: Wenn ich https://test-ipv6.com/ aufrufe, meldet er mir „Keine IPv6-Adresse erkannt“, jedoch sowohl im Pädnetz wie im WLAN. Im WLAN tut aber NCBI-Blast… Im WLAN funktioniert auch das dig, allerdings nur:
nicht:
dig @10.5.0.1 blast.ncbi.nlm.nih.gov
Das wäre eigentlich die Adresse des OPNsense im WLAN. Hmmm.
Grüße,
Stefan
Ok, dann hat also die OPNsense bzw. der Unbound DNS der OPNsense ein Problem damit den Namen aufzulösen bzw. findet den zuständigen Nameserver(ns) für diese Domain gar nicht, löst aber andere Hostnamen problemlos auf.
Vielleicht kann man das Logging des Unbound DNS ins syslog in den Einstellungen aktivieren. Dort kann man auch Queries loggen lassen. Vielleicht sieht man dann die Probleme.
Viele Grüße
Klaus
Das oben beschriebene Verhalten gilt neu auch für admin.ch. Nicht so gut für eine Schule in der Schweiz.
Lösung per workaround: im webinterface von opnsense bei services / unbound dns / override / override domain
domain: admin.ch, ip: 1.1.1.1 (bzw. anderer für admin.ch funktionierender nameserver); unbound neu starten.
Diagnose:
Auf Konsole von linuxmuster server
dig @firewall admin.ch
ergibt status: SERVFAIL, ANSWER:0
dig @1.1.1.1 admin.ch funktioniert dagegen
Vertiefte Diagnose:
dig @1.1.1.1 admin.ch ns
liefert die für die domain zuständigen Nameserver, etwa ins1.admin.ch
dig @ins1.admin.ch admin.ch
funktioniert, aber liefert: WARNING: recursion requested but not available
und
dig @firewall admin.ch
erzeugt im log von unbound (webinterface)
error: read (in tcp s): Connection refused for [ip Adresse] port 53
Zusatz (edit): Hatte zuvor opensense via webgui von 19.x über 20.x auf 21.1.5 aktualisiert; Fehler ist unverändert geblieben.)
Hallo spblinux,
das sind offenbar zwei unterschiedliche Probleme. Wenn ich bei mir admin.ch aufrufe, kommt eine Fehlermeldung von opnSense. Wenn ich ncbi aufrufe, tut es (manchmal) ein paar Klicks (2-5) lang, dann plötzlich nicht mehr, keine opnSense-Fehlerseite, sondern die „Server nicht gefunden“-Seite von Firefox.
Hab deinen workaround hier ausprobiert, admin.ch funktioniert dann (hätte hinter dieser Adresse aber nicht den Schweizer Bundesrat vermutet…), ncbi nur ein paar Klicks lang… Übrigens auch von meinem heimischen Rechner aus, wenn ich den Verkehr per Wireguard übers Schulnetz leite. Wenn ich die Verbindung kappe (dann macht mein heimischer Adguard wieder die DNS-Anfragen), läuft es sofort wieder. Am Client liegt es also nicht.
Grüße,
Stefan