Service zwingen, eine bestimmte IP-Adresse zu nutzen?

[Bob.Dig]

Ich habe hier zu hause auf einer Maschine zwei IPv6-Adressen mit jeweils eigenem PTR (DNS).
Nun möchte ich, dass ein Server/Service/Programm für ausgehende Verbindungen nur die "richtige" IP verwendet, nämlich die mit der passenden PTR-Adresse.
Aber das scheint alles andere als trivial zu sein, viele Programme erlauben zwar das "Listening" einzustellen, aber wohl nicht die nur-ausgehenden Verbindungen.

Täusche ich mich da?
Z.B. mein E-Mail-Server erlaubt das "Binding" nur auf eine Adresse, was in der heutigen Zeit mit IPv4 und IPv6 schon zu wenig ist.

 

[KillerCow]

Wenn du jetzt noch verrätst, um welche Software es sich handelt und vor allem welches OS zum Einsatz kommt, dann kann dir vielleicht sogar jemand helfen.

 

[Bob.Dig]

Wenn du jetzt noch verrätst, um welche Software es sich handelt und vor allem welches OS zum Einsatz kommt, dann kann dir vielleicht sogar jemand helfen.

Diverse... 😉
Ist wohl einfacher, für jede eine eigene Maschine zu nehmen. Schade, wo doch eine Maschine gleich mehrere IPv6-Adressen haben kann, aber viele Softwareentwickler rechnen wohl noch nicht damit.

 

[KillerCow]

Notfalls nen proxy vor die Anwendung hängen? nginx oder haproxy oder so.

 

[Bob.Dig]

Notfalls nen proxy vor die Anwendung hängen? nginx oder haproxy oder so.

Nur mal theoretisch, es geht um unaufgeforderte ausgehende Verbindungen (Beispiel E-Mail wird vom Server verschickt), würde da tatsächlich haproxy helfen?

 

[snaxilian]

Bei Email unterstelle ich mal die Nutzung von Linux. So oder so entscheiden sich ausgehende Verbindungen anhand der Routingtabelle im OS und da dann erstmal anhand der Default Route wenn es Richtung Internet gehen soll. Hast du mehrere Möglichkeiten bzw. willst abweichend von der Default Route gehen dann ginge dies mit Policy Based Routing. Entweder am Host direkt mittels iptables oder zentral am Router/Firewall sofern diese die Funktionen unterstützt.
Alternativ falls du deine Dienste mit Docker betreibst könnte man das so lösen indem man die Container per host network nach außen anbindet aber das hat andere unschöne Nebeneffekte sofern man nicht nur docker auf nem Single Host betreibt.

 

[Bob.Dig]

Was wäre eigentlich der deutsche Fachbegriff für "unsolicited"?

Das ganze ist jetzt nur theoretisch, weil nur @home und außerdem habe ich es schon aufgeben, es ist einfacher jeder "Anwendung" ihre eigene Maschine mit eigener IP-Adresse (mit PTR) zu geben als mehrere Anwendungen auf der selben Maschine mit mehreren IP-Adressen zu betreiben, die sich dann nur ihre passende IP für PTR greifen.
Ich denke, da ist einfach viele Software nicht für ausgelegt.
Keine Ahnung wie Docker arbeitet, insbesondere in der Beziehung.

Wie gesagt, es geht mir speziell um unaufgeforderte ausgehende Verbindungen.

 

[Raijin]

Diverse... 😉

Das ist wenig hilfreich. Sollen wir jetzt antworten, dass es auch "diverse" Lösungen gibt? Linux: PBR, Windows: ForceBindIP.

Wenn du aber keine Details lieferst worum es überhaupt geht, kann man bestenfalls raten und das geht dann im worst case vollkommen am Thema vorbei, weil man gar nicht weiß was du vorhast...


Grundsätzlich ist es so, dass beim Programmieren von Netzwerkanwendungen bestimmte Funktionsaufrufe an das Betriebssystem gestellt werden.

Das Öffnen eines Ports - explizit auf einer bestimmten IP des Systems oder implizit auf allen IPs

Das Abschicken eines Pakets an ein Ziel - explizit von einer bestimmten Quell-IP oder implizit durch das OS entschieden.


Wenn eine Server-Anwendung nicht vorsieht, durch Konfiguration die IP des Servers einzuschränken - also so, dass der Dienst nur auf LAN1 verfügbar ist, aber nicht auf LAN2 - dann kann man das im Prinzip nur über die Firewall des Betriebssystems auf den unerwünschten Ports blocken. Hört der Service hingegen nur auf einer IP, man möchte ihn aber auf der anderen IP auch verfügbar machen, muss man dies über einen Proxy-Service, o.ä. aktiv so umbiegen, dass die Pakete trotzdem ihr Ziel finden.

Wenn eine Client-Anwendung nicht vorsieht, durch Konfiguration die Quell-IP bzw. das Absender-Interface auszuwählen, wird das Pakete stur an das OS durchgereicht und dort wird anhand der Routingtabelle entschieden über welches Interface bzw. Gateway das Paket rausgeht. Je nach OS stehen einem dazu verschiedene Möglichkeiten zur Verfügung. Unter Linux ist es am einfachsten, weil Linux PBR beherrscht, Policy Based Routing. Das heißt, dass man der Routing-Engine explizit mitteilen kann, dass bestimmte Pakete, die einem Matching entsprechen (zB ein bestimmter Port, eine bestimmte Quelle, etc) explizit anders geroutet werden sollen. Windows kann kein PBR. Hier muss man sich dann Zusatztools wie ForceBindIP bedienen. Diese Tools schalten sich zwischen die Anwendung und Windows und fangen sämtliche Netzwerkaufrufe ab und biegen sie aktiv um. Übergibt die Anwendug also ein Paket ohne Angabe der Quelle an Windows, müsste normalerweise Windows entscheiden von wo das Paket abgeschickt wird. ForceBindIP schaltet sich dazwischen, fängt das Paket ab und sagt Windows dann explizit, dass das Paket über Schnittstelle xy rausgehen soll.

 

[Bob.Dig]

fängt das Paket ab und sagt Windows dann explizit, dass das Paket über Schnittstelle xy rausgehen soll.

Bei mir wäre es ja sogar das selbe Interface, nur halt mit einer bestimmten IPv6, von denen selbiges gleich mehrere besitzt.
Was ich sagen will, mir fehlt einfach bei vielen Anwendungen, dass man sie auf eine bestimmte Adresse "binden" kann, wegen PTR. "Listen" kann man ja bei den meisten einstellen.

 

[snaxilian]

unaufgefordert oder unverlangt, je nach Kontext auch freiwillig oder ungebeten wäre die passende Übersetzung.

Wie gesagt: Ausgehende Verbindungen richten sich nach den vorhandenen Routen da diese nur nach IPs gehen und das Protokoll egal ist. Willst du anhand des verwendeten Protokolls oder ggf. der Anwendung unterscheiden brauchst du Policy Based Routing aber das macht gerade am Anfang wenn man damit einsteigen will echt keinen Spaß. Been there, done that und bin froh dass ich das am Ende an unsere Netzwerker abgeben konnte^^

Wie viele Anwendungen nutzt du denn, die einen PTR erfordern? In der Regel ist dies doch nur noch Email

 

[Bob.Dig]

Wie viele Anwendungen nutzt du denn, die einen PTR erfordern? In der Regel ist dies doch nur noch Email

Richtig, ist einfach nur "nice to have" und keinerlei echte Anforderung. Geht eh nur um meinen Homeserver ohne Bezug zu irgendwas.

Ich sehe es halt in der "Firewall", wenn man da die Logs auswertet, dass PTR da schon sinnvoll ist.

Ergänzung (9. April 2020)

Das heißt, dass man der Routing-Engine explizit mitteilen kann, dass bestimmte Pakete, die einem Matching entsprechen (zB ein bestimmter Port, eine bestimmte Quelle, etc) explizit anders geroutet werden sollen.

In meinem theoretischen Beispiel müsste ich also für meine ausgehenden Verbindung den bzw die möglichen Zielports definieren um dann eine bestimmte IP-Adresse oder interface zu benutzen, ich denke das wäre den Aufwand wirklich nicht wert.

 

[Ortan]

Policy based routing ist da die einzige saubere Lösung.
In diesem Beispiel wird’s beschrieben.

Generell:
Eingehende Verbindungen per Listen Port konfigurieren.
Ausgehende Verbindungen per policy routing konfigurieren.
Aufpassen musst du bei stateful firewalls, die lassen es nicht zu dass z.B der Request an einen Server an die IP x von der IP y beantwortet wird.

Edit:
Habe echt "Policy Baseball routing" geschrieben, haha.
Wörterbuch und Handy... btw. es gibt keinen face palm smily hier

 

[Raijin]

In der Tat, verschiedene IPs für dieselbe Verbindung sind so eine Sache. Üblicherweise wird ein Paket, das auf einem Interface mit IP X eingeht, auch wieder mit IP X abgeschickt. Wenn man dort nun eingreift und die Antwort eben nicht über X zurückschickt, sondern mit der IP Y, dann wird das Ziel dies ggfs nicht als Antwort anerkennen. Es gibt Szenarien, in denen das nicht so ist bzw. in denen das sogar explizit ausgenutzt wird. Das nennt sich dann zB Hole Punching und wird beispielsweise von Diensten wie TeamViewer, Skype und Co ganz gerne genutzt, um Firewalls auszutricksen.


Banales Beispiel:

In einem Raum stehen Frank, Rebecca und Horst. Stefan steht vor der Tür und ruft hinein: "Rebecca? Bist du da?" Er erwartet also eine Antwort von Rebecca. Nu antwortet aber Horst und sagt "Ja, ich bin da!". Das hilft Stefan nicht weiter und er ignoriert diese Antwort. Im besagten Hole Punching Szenario würde er jedoch auch diese Antwort akzeptieren - er wurde also ausgetrickst.

Das ist natürlich nur ein rudimentäres Abbild der Netzwerkkommunikation bzw. beschreibt eben die erwähnte stateful firewall. Dort wird eine Verbindung nämlich in 4 Kategorien eingeteilt

new - das erste Paket der Verbindung (SYN-Flag an)
established - das SYN-Paket wurde mit ACK bestätigt
related - eine mit einer bestätigten Verbindung verwandte Verbindung (zB FTP command vs data connection)
invalid - alles was nicht in die anderen Kategorien reingehört

Wenn nu eine Antwort von einer anderen Quelle reinkommt, die eben nicht zur "new" Verbindung passt, wird sie als invalid eingestuft und geblockt.


Das ist eben auch ein Grund dafür warum mehrere IP-Adressen auf ein und demselben Interface unpraktisch sind. Es macht die Sache kompliziert und ist fehleranfällig.



Übrigens: Meine Ausführungen beziehen sich primär auf IPv4. Mit IPv6 hatte ich weder privat noch beruflich und leider auch während des Studiums keinerlei Berührungspunkte und bisher hatte ich noch nicht den Elan, mich im Detail damit zu beschäftigen. Daher kann ich nicht 100%ig sagen inwiefern das alles auch auf IPv6 zutrifft.

 

[Ortan]

Übrigens: Meine Ausführungen beziehen sich primär auf IPv4. Mit IPv6 hatte ich weder privat noch beruflich und leider auch während des Studiums keinerlei Berührungspunkte und bisher hatte ich noch nicht den Elan, mich im Detail damit zu beschäftigen. Daher kann ich nicht 100%ig sagen inwiefern das alles auch auf IPv6 zutrifft.

Das ist bei IPv6 nicht anders, zumindest was das Connection Tracking angeht.

Als Beispiel bei Router, mit mehreren WAN Verbindungen nach außen, werden beim Loadbalancing auf die WAN Interfaces gewichtete RoundRobin Algorithmen verwendet um die ausgehenden Verbindungen aufzuteilen. Die Antwort vom Server kommt wieder zurück an die Adresse von der sie gesendet wurde.
Genau dort liegt das Problem des TE, und genau hier greift policy based routing. Hier auch noch eine Erklärung die mehr ins Detail geht.

 

[Bob.Dig]

Dass die Antwort zurück kommt ist nie mein Problem, es geht mir nur um unaufgeforderte ausgehede Verbindungen, wenn zwei oder mehr IP(v6) vorhanden sind. Aber wie gesagt, lohnt alles nicht und mit einer NIC/IP pro Service und damit Server ist es gegessen.

 

[Ortan]

Dass die Antwort zurück kommt ist nie mein Problem, es geht mir nur um unaufgeforderte ausgehede Verbindungen, wenn zwei oder mehr IP(v6) vorhanden sind. Aber wie gesagt, lohnt alles nicht und mit einer NIC/IP pro Service und damit Server ist es gegessen.

Das ist sicherlich die einfachste und effektivste Lösung.

 

[Bob.Dig]

Das ist sicherlich die einfachste und effektivste Lösung.

Hab gerade überlegt, das Ganze mit NAT in der pfSensel zu lösen, geht aber nicht bei IPv6. 😄

 

[Ortan]

Hehe, bei ipv6 wir alles geroutet, ohne NAT kommt dann NPt ins spiel.
Policy based routing geht mit pfSense echt gut und einfach, ist wiederum bei ipv4/6 gleich.
OT: pfSense ist IMHO einer der besten firewalls und kann fast alles umsetzen.

Du kannst jetzt z.B. virutalisieren (Docker, lxc, kvm, whatever) und dem genau eine NIC geben.
Oder dich mit dem "Problem" auseinandersetzen

Wie hast du die Infrastruktur aufgesetzt?
Hast du eine pfSense als FW zum Inet?

 

[Bob.Dig]

@Ortan pfSense ist mein einziger Router im Homenet.
Ich habe von Routing aber ehrlich gesagt keine Ahnung. Mir gefällt auch nicht, wenn ich irgendwas in den Hosts selbst einstellen muss und pfSense selbst dürfte für mein "Problem" dann schon zu spät sein.

 

[Ortan]

@Ortan pfSense ist mein einziger Router im Homenet.
Ich habe von Routing aber ehrlich gesagt keine Ahnung. Mir gefällt auch nicht, wenn ich irgendwas in den Hosts selbst einstellen muss und pfSense selbst dürfte für mein "Problem" dann schon zu spät sein.

Das kann leicht sein (ziemlich sicher), NAT gibt is in dem Sinne ja nicht bei ipv6.
Das routing ist auf dem Host selbst lösen.

Wie schaut deine Netzwerkkonfiguration aus?