automatisch gesetzte IP in /etc/hosts hat sich geändert -> wie ändern?

[Th0mas]

Hallo zusammen,

mein OPNsense Gateway hat viele verschiedene Netzwerkinterfaces und routet einige Subnetze.
Nehmen wir an ich hätte unter System>Settings>General folgendes eingestellt:
Hostname=opnsense
Domain=example.com
Nehmen wir weiter an meine Interfaces IPs wären folgende:
WAN (ix0)=123.123.123.4
LAN1 (ix1)=192.168.0.1
LAN2 (ix2)=192.168.1.1
LAN3 (ix3)=192.168.2.1

Bisher war dann immer die /etc/hosts wie folget automatisch generiert worden:
127.0.0.1       localhost localhost.example.com
123.123.123.4   opnsense.example.com opnsense

Immer Sonntags um 8Uhr wird geprüft ob eine neue Firmware verfügbar ist und wenn ja, installiert.
Aktuelll installiert ist opnsense 21.1.5 amd64 (installiert am Apr 25 08:01:06 CEST 2021)

Nun habe ich heute das GW seit längerem rebootet und anschließend sah meine /etc/hosts so aus:
127.0.0.1       localhost localhost.example.com
192.168.1.1   opnsense.example.com opnsense

Der installierte bind name server antwortet nun auf externe Anfragen nach opnsense.example.com mit der internen LAN2 IP.
Weil das keinen Sinn macht und zu Problemen führt habe ich die /etc/hosts geändert und nach einem Reboot war sie dann wieder auf die LAN2 IP zurückgesetzt.

Wo kann man definieren welches Interface für die Erstellung der /etc/hosts Datei herangezogen wird?

Vielen Dank und liebe Grüße,
Th0mas

[Th0mas]

Habe herausgefunden, daß nicht der bind die informationen aus der /etc/hosts herauszieht, sondern mein AdGuard, was ebenfalls auf dem opnsense server läuft und im bind als forwarder eingeragen ist.

Das Grundproblem ist aber unverändert: Wie kann ich sicherstellen, daß in der FQHN-Zeile der /etc/hosts Datei wieder die IP meines WAN interface steht und nicht die des LAN2.

[franco]

Hmm, das Grundproblem ist ein Seiteneffekt der gar nicht gewünscht ist, da LAN oder OPTx bevorzugt wird:

https://github.com/opnsense/core/blob/2cce435c793434bc0c5f3d335498a8c515fa2052/src/etc/inc/system.inc#L365

Fast schon witzig ist wie WAN da überhaupt auftaucht, vermutlich weil es nicht das originale "wan" ist, aber auch dann würde das "lan" immer bevorzugt werden sofern dies nicht deaktiviert wurde.


Grüsse
Franco

[Th0mas]

Hallo Franco,

Vielen Dank, daß du dir die Zeit genommen hast mein Problem zu durchleuchten!

Ich habe die Logik im Code nun verstanden und erkenne, wieso er mein ix2 interface nutzt. Ich hatte mein Beispiel versucht so zu wählen, daß es leicht zu verstehen ist. In Wirklichkeit heißen die Interfaces (die Meisten davon LAGGs über mehre 10GbE Ports und sonstigen VPN Interfaces) bei mir anders. Die Interfacenamen stehen für die dahinter liegenden Secure-Zonen/VLANs. Diese nun mit einer vorgestellten Nummerierung umzubenennen, damit das "WAN" Inferface nach dem Sort an der 1. Stelle kommt, scheint mir widersinnig.

Ich suche auch noch nach der Ursache, wieso ich das Problem erst seit diesem Reboot habe. Die Implementierung scheint sich laut dem GIT Repo in letzter Zeit hier nicht geändert zu haben. Wurde evtl. früher beim Reboot die /etc/hosts nicht überschrieben und ich hatte diese beim Einrichten damals einfach angepaßt?

Ich finde die statische Kopplung der Logik an die Default Interface-Namen ungeschickt da man die Namen über das UI ja beliebig customizen kann und das nach Namen sortierte, erste Interface dann sicher nicht immer zufällig das richtige ist. Ohne den Code zu lesen, versteht ein Anwender nicht, wieso das System ein vermeintlich willkürliches Interface für die Erzeugung der /etc/hosts-Datei heranzieht.

Ideal fände ich, wenn man dieses Interface über das UI konfigurieren könnte.
Wenn das nicht in eurem Sinne ist, dann wäre es zumindest gut, wenn man das automatische Überschreiben der /etc/hosts beim Boot deaktivieren könnte, um diese Datei dann von Hand richtig konfigurieren zu können.

Als Workaround (weil das System morgen nach dem Feiertag ja wieder laufen muß) habe ich im Bind nun eine rpz zone als Overwrite-Zone angelegt und diese als "response-policy" gesetzt. Damit kann ich selektiv den Namen opensense.example.com (um im Beispiel zu bleiben) überschreiben und verhindern, daß er die Anfrage an AdGuard forwarded. Somit verhindere ich, daß AdGuard diesen Namen über die /etc/hosts versucht aufzulösen.

Das ist zwar ein funktionierender Workaround für exakt mein Problem, aber bedeutet, daß der Admin eine /usr/local/opnsense/service/templates/OPNsense/Bind/+TARGETS.D/named.conf anlegen muss, um diese Overwrite-Zone in die response-policy Liste aufzunehmen, weil die Aufname von response-policy Einträgen im Bind UI nicht vorgesehen ist. Eine überschriebene named.conf birgt immer die Gefahr, daß sich Template-Namen im UI ändern und diese nach einem Update nicht mehr funktioniert, oder daß neue Features im Bind Plugin nicht wirksam werden.

Liebe Grüße,
Th0mas