Gateway mit internem Netz, externe IP anzeigen

[d4f]

Ist-Zustand:
Eine dedizierte IP (bspw. 1.2.3.4 ) wird am (Security)gateway terminiert welcher die Pakete per DNAT auf ein "internes" privates Netzwerk weiterleitet. das Gateway hat intern selbst die IP 192.168.0.1 und leitet die Pakete nach 192.168.0.10 weiter; also quasi eine DMZ.

Damit aber nicht die Server-Dienste und laufende Skripte verwirrt werden, will ich dass die Dienste intern an der öffentlichen IP lauschen, also 1.2.3.4
(Lizenzierungs-Tools sind immer so eine Sache und generell nicht sehr klug...)

Mein Versuch war eine interne Bridge zu erstellen welche per DNAT die Pakete dann erhält. Das schien auch einige Zeit gut zu gehen jedoch verschwand nach 20 Minuten - ohne weitere Änderungen - aus dem Netz. Erst ein ifdown der Bridge brachte ihn wieder. Weitere Versuche brachten ihn direkt down. Irgendein Cache scheint also zu wirken - nur was?

Hat jemand einen Vorschlag wie ich das besser lösen könnte oder was mir da in das Netzwerk pfutscht? Routen sind es nicht, zumindest legt er keine sichtbare an.

 

[PapaBaer]

Ich versuch mal einen Schuss: Am internen Host eine virtuelle Netzwerkkarte einrichten und die öffentliche IP/32 drauf legen. Dann den Port an der internen IP am internen Server ein weiteres mal DNATen zurück auf die öffentliche IP.

Da die schmalere Netzwerkmaske der internen Host-Route Vorrang hat, müssten die Pakete am virtuellen Interface aufschlagen.

 

[vb-server]

Naja, wenn die IP nicht auf den Host routed ist, geht das nicht. Ich würd da ProxyARP und eine Hostroute auf das interne Netzwerkinterface machen.

 

[d4f]

Am internen Host eine virtuelle Netzwerkkarte einrichten und die öffentliche IP/32 drauf legen. Dann den Port an der internen IP am internen Server ein weiteres mal DNATen zurück auf die öffentliche IP.

Das hatte ich ja versucht, lief aber kräftig schief da der ganze Host aus dem Netz verschwand.

Ich würd da ProxyARP und eine Hostroute auf das interne Netzwerkinterface machen.

Ob das wohl was wird? Naja probieren geht über studieren

 

[PapaBaer]

Mein Versuch war eine interne Bridge zu erstellen welche per DNAT die Pakete dann erhält.

Keine Bridge. Unter BSD wäre das ein vether0, finde gerade den passenden Treiber für Linux nicht.

EDIT:

modprobe veth
ip link add type veth 
ifconfig veth0 123.123.123.123/32
tracepath 123.123.123.123
  1:  123.123.123.123                                       0.028ms reached

 

[Joe User]

Die externe IP einfach transparent an das interne System durchreichen. Beherscht jede halbwegs brauchbare Firewall.

 

[d4f]

Die externe IP einfach transparent an das interne System durchreichen.

Das ist -vermutlich eher weniger durch die Firewall als durch den imho etwas frickligen Netzaufbau - leider nicht möglich. Daran kann ich aber leider nichts ändern.

Keine Bridge. Unter BSD wäre das ein vether0

veth scheint nur von OpenVZ eingesetzt zu werden und deren spezifisches Problem zu lösen: https://openvz.org/Virtual_Ethernet_device
Eine Bridge ohne Port-Bridging wäre doch aber auch genau das; ein virtuelles Netzwerk-interface mit dem man tun und lassen kann man was man will. Theoretisch.

 

[Joe User]

Kannst Du den Netzaufbau für das betroffene System mal in ASCII-Art darstellen?

Ich hatte beim RootForum nämlich vor Kurzem noch ein ähnliches/gleiches Setup und keine Probleme damit (allerdings unter FreeBSD, wobei das unrelevant sein sollte).
Es waren zwei Firewalls (Failover) vorgelagert, welche die externe IP transparent an die interne IP unserer Systeme (CARP-Failover) durchgereicht haben, so dass die Dienste ohne "Hacks" arbeiten konnten. Als Gateway fungierte hingegen die interne IP der Firewalls, welche die ausgehenden Pakete wiederum transparent von unserer internen IP auf die externe IP umgeschrieben haben.
Ich habe auf unseren Systemen also ausschliesslich interne IPs für die Netzwerkinterfaces genutzt und konnte die Dienste trotzdem auf der externen IP lauschen lassen. Das lief völlig problemlos.

Hoffe, das war halbwegs verständlich.

Wie genau die Firewalls konfiguriert wurden entzieht sich allerdings meiner Kenntnis, da ich keinen Zugriff darauf hatte. Es waren aber Endian Firewalls, falls das helfen sollte.

 

[elias5000]

Ich würd da ProxyARP und eine Hostroute auf das interne Netzwerkinterface machen.

Das beschriebene Setup hatte ich für eine DMZ mal längere Zeit laufen und ProxyARP ist genau das, was man dafür nutzen möchte. Auf dem Gateway lief damals Linux mit iptables. Zum Einrichten des Routings hatte ich shorewall verwendet. Damit ist das Setup relativ leicht einzurichten.

 

[bkxxl]

Guten Morgen,

da es sich um eine Lösung aus unserem Hause handelt, hättest du auch unsere Netzwerkspezialisten fragen können.

Also, auf dem Server hinter der Firewall ist immer die interne IP patziert, in diesem Fall nicht die externe. Die Firewall routet den Traffic auf IP X an interne IP X weiter, wenn man es so einstellt, genauso umgekehrt, man kann von IP X stammende IP über eine bestimmte externe IP in das Internet versenden.

Du musst hierfür die entsprechende Masquerading sowie DNAT Rule setzen. Die Firewall macht dann den Rest.

Eine Alternative dazu ist der Bridged Modus. Beim Bridged Modus müsste aber die Firewall direkt neben dem Server platziert werden. Beim Bridged Modus kannst du die externen IPs auf deiner LAN Karte platzieren und die Firewall ist dein neuer Netzwerk Uplink über eine Crossover Verbindung. Haben wir letztens für einen Kunden realisiert, dessen Anwendung nur externe IPs zugelassen hat. Ist aber denke ich in diesem Fall nicht notwendig.

 

[d4f]

Also, auf dem Server hinter der Firewall ist immer die interne IP patziert, in diesem Fall nicht die externe. Die Firewall routet den Traffic auf IP X an interne IP X weiter, wenn man es so einstellt, genauso umgekehrt, man kann von IP X stammende IP über eine bestimmte externe IP in das Internet versenden.

Das ist das aktuelle Setup, stimmt. Allerdings ist dies aus mehreren Gründen nicht unsere bevorzugte Realisierung (Stichwort Lizenzierung) weshalb wir versuchen _virtuell_ die externe IP auf dem Server zu "simulieren".

Eine Alternative dazu ist der Bridged Modus. Beim Bridged Modus müsste aber die Firewall direkt neben dem Server platziert werden.

Dazu extra Server zu schieben ist technisch gesehen ja nicht unbedingt notwendig wenn man Zugriff auf die Host-Konfiguration hat.
Genau das versuchen wir ja mit DNAT-Regeln respektiv nun ProxyARP einfacher zu lösen.

da es sich um eine Lösung aus unserem Hause handelt, hättest du auch unsere Netzwerkspezialisten fragen können

Die Realisierung sollte ja generell genug sein als dass ein öffentliches Forum es lösen kann =) Die bislang angegebenen Vorschläge, zumal in Bezug auf ProxyARP, sehen ja vielversprechend aus für unseren Bedarf.
Aus praktischer Erfahrung mit der ...uuuuuhm... "Netzwerkabteilung" einiger anderer Anbieter bevorzuge ich generell eine direkte Lösung ohne Support-Anfrage. No offense

 

[s24!]

Da d4f momentan nicht viel Zeit hat, übernehme ich als ebenfalls Projektbeteiligter mal hier. Mit ProxyARP waren wir nicht allzu weit gekommen. Aktueller Stand laut ihm:

Wir versuchen dem Server lokal seine externe IP zu simulieren indem diese auf einem Alias von loopback konfiguriert wird. Dies erfüllt auch alle unsere Anforderungen und funktioniert tadellos, jedoch nur rund 20 Minuten bevor der Server nicht mehr erreichbar ist.
Es sind für den loopback-Adapter kein ARP-proxying, keine NAT-Regeln und auch kein Routing hinterlegt sowie ARP-Announcing soweit möglich testweise abgeschaltet.
Der Server kann durch ein Deaktivieren und erneutes Aktivieren der externen Adresse im Security Gateway reaktiviert werden was auf eine inkorrekte Route im Provider-Netz schliessen lässt.

Mit dem letzten Satz ist (meines Wissens) gemeint, dass unsere Konfiguration offensichtlich früher oder später die externe IP dem Security Gateway "klaut" und diese zu übernehmen versucht.

Das Ganze sieht so in der interfaces-Datei aus:

auto lo:1
iface lo:1 inet static
        address 84.200.83.104
        netmask 255.255.255.255
        broadcast 0.0.0.0

Außerdem definiert:

echo 1 > /proc/sys/net/ipv4/conf/lo/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
ip route add 84.200.83.104/32 dev lo:1

Weiß jemand weiter?

Viele Grüße
Tim

 

[vb-server]

Wieso die IP auf lo routen? Kannst sie ja grad so gut am WAN adden?

 

[s24!]

Missverstehe ich dich oder ist das die Antwort?

Damit aber nicht die Server-Dienste und laufende Skripte verwirrt werden, will ich dass die Dienste intern an der öffentlichen IP lauschen, also 1.2.3.4

Die externe IP soll auf dem Server eben nur "virtuell" sein.

 

[elias5000]

Normal isses so, dass man die IP auf dem Server auf dem Interface added, das im selben Netz ist wie das Gateway. Dann konfiguriert man auf dem Gateway ProxyARP, damit es die IP auf den internen Server durchreicht. Ich bin mir allerdings gerade unsicher, ob man dafür nicht auf dem Gateway mindestens zwei IPs braucht (eine fürs Gateway selber und eine zum durchreichen).

 

[s24!]

Nun, am Security Gateway können wir aber wie gesagt nichts ändern. D.h. rein gar nichts.

 

[jue]

Warum nutzt ihr nicht auch intern die öffentlichen IP-Adressen? Spricht da etwas gegen? Als ganz ohne interne IP ...

Auf der Firewall muss nacht außen hin ProxyARP aktiviert werden. Wie ihr das ja bereits getan habt. Zusätzlich muss auf der Firewall eingetragen werden, dass jene externe IP über das Interface nach innen erreichbar ist.

Der eigentliche Server bekommt dann die IP fest zugewiesen. Als Standard-Gateway trägt man dann entweder die IP der Firewall ein. Hier muss auf dem Server natürlich auch wieder bekannt gemacht werden, dass die IP der Firewall auf dem internen Netz liegt.

Zum Debugging ist es immer recht zuträglich, sich via tcpdump mal auf die Firewall zu setzen und zu sehen wo bspw. ICMP-Traffic lang fließt.

 

[s24!]

Hört uns hier eigentlich keiner zu? Wir haben keinen (SSH-)Zugriff auf die Firewall! Unsere Konfigurationsmöglichkeiten beschränken sich auf den eigentlichen Server.

Konnten das Problem übrigens mittlerweile lösen, ich poste das Endergebnis die Tage noch mal.