OPNsense Forum
International Forums => German - Deutsch => Topic started by: white_rabbit on May 13, 2022, 11:41:03 am
-
Hallo.
Hier gibt es ein merkwürdiges Phänomen, für das ich keine Erklärung habe.
Wir haben eine DMZ eingerichtet, in der sich ein paar Clients "von außen erreichbar" tummeln.
Wenn wir "von innen" auf diese Clients zugreifen, greift eine Unbound-Regel, die den Domainnamen direkt mit der internen IP-Adresse verknüpft. Soweit so gut.
Neulich musste zu einem dieser Clients eine Portweiterleitung geschaltet werden, damit man ihn direkt von außen per ssh erreichen kann. Auch das lief problemlos.
Nun ist es aber so, dass ich genau diese eine IP-Adresse aus dem Managemnent-Subnetz nicht mehr erreichen kann. Die Portweiterleitung (die übrigens nur einen SSH-Port betraf und nichts mit https:// zu tun haben konnte) ist also nicht mehr aktiv.
Jeden anderen Client in der DMZ erreiche ich und die Firewallregeln auf der OPNSense sind auch so eingestellt, dass ich aus dem Management-Subnetz auf die DMZ darf.
Wenn ich es mit "tracepath 172.17.17.199" (die IP des betroffenen Clients) versuche, gelangt die Anfrage bis zur Firewall und liefert anschließend nur noch "keine Antwort". Bei jedem anderen Client in dem Segment kommt eine Antwort.
Daher die Frage: Was kann das sein? Ich hatte die Hoffnung, dass das Problem auf der OPNSense zu suchen ist.
Auf dem Client läuft übrigens keine eigene Firewall.
Bis vor kurzem lief das noch und das Webinterface des Clients war sowohl unter https://name.meine-domain.de als auch unter
https://172.17.17.199" erreichbar. Jetzt gibt's leider einen Timeout.
Mein Eindruck ist (ohne es beweisen zu können), dass es seit der Portweiterleitung so ist (auch wenn das eigentlich wenig Sinn ergibt).
Habt ihr eine gute Idee, wonach man da suchen kann?
(Von einer Shell auf der OPNSense funktioniert es natürlich)
Danke für eine gute Idee!
-
> Mein Eindruck ist (ohne es beweisen zu können), dass es seit der Portweiterleitung so ist (auch wenn das eigentlich wenig Sinn ergibt).
Kannst du vielleicht die Weiterleitung mal rausnehmen/disablen und schauen ob es danach funktioniert? Wäre zwar ungewöhnlich aber damit könnten wir das wenigstens ausschließen.
Cheers
-
Die Weiterleitung ist wieder deaktiviert -- es geht aber trotzdem nicht.
Mittlerweile ist mir noch etwas anderes aufgefallen. Auf dem Client in der DMZ habe ich mit
route -n nachgesehen, was da los ist.
Das Ergebnis sieht aus nicht nachvollziehbaren Gründen so aus:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.17.254 0.0.0.0 UG 0 0 0 ens18
172.17.17.0 0.0.0.0 255.255.255.0 U 0 0 0 ens18
172.17.17.0 172.17.17.254 255.255.255.0 UG 0 0 0 ens18
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.0.0 0.0.0.0 255.255.240.0 U 0 0 0 br-24ce8799f513
Die letzte Zeile kommt mir seltsam vor, denn das 192er Netz ist dasjenige, von dem aus ich auf das 172er Netz zugreifen will. Sieht nach einer falschen docker-Konfiguration aus, oder?
Falls das der Fehler ist, wäre es zwar hier OT -- dennoch würde ich mich natürlich über einen Schubser in die richtige Richtung freuen. (Warum das plötzlich so ist, ist damit allerdings auch noch nicht klar)
-
Das war's tatsächlich ... ein docker-Problem!
Hier steht die Lösung, falls sonst noch jemand darüber stolpern sollte. Sorry, dass das hier OT war ...
https://blog.uni-koeln.de/rrzk-knowhow/2020/09/23/privaten-ip-adressbereich-von-docker-anpassen/
https://stackoverflow.com/questions/53347289/docker-error-cannot-start-service-network-7808732465bd529e6f20e4071115218b