Öffentliche IPs hinter einem (Mikrotik-) Router nutzen
Es gibt mehrere Ansätze einen Host (Server…) „hinter“ einem Router über eine öffentliche IP erreichbar zu machen. Um den betreffenden Host jedoch direkt mit einer öffentlichen-IP auszustatten sind nur zwei Methoden üblich: Bridging oder Proxy-ARP.
Hier wird angenommen der Edge-Router ist Teil eines öffentlichen Subnetzes, in dem es nutzbare (freie) IPs gibt. Sollte vom ISP direkt ein Netz zum Edge-Router geroutet werden, können natürlich eigenständig (Unter-) Subnetze gebildet werden.
- Methode 1: L2 – Bridging
Das öffentliche Subnetz wird per Switch/VLAN direkt an den/die Hosts durchgereicht.
+ öffentlich IP kann direkt auf dem Host konfiguriert werden
– Firewalling/Queueing muss auch direkt auf dem betreffenden Host gemacht werden (oder per L2-Filtern auf dem Switch)
– Eintrag von WAN-seitigem Broadcast-Traffic bei Nutzung eines Transfer-VLANs möglich (Broadcast-Filter auf Switches möglich)
- Methode 2: L2/L3 – Proxy-ARP
Öffentliche IP wird „hinter“ dem Edge-Router per Proxy-ARP an dem Host verfügbar gemacht.
+ öffentliche IP kann direkt auf dem Host konfiguriert werden
+ Firewalling/Queueing läuft über Edge-Router
– höherer Konfigurationsaufwand bei komplexen Topologien
- Methode 3: L3 – DNAT (ÖFFENTLICHE IP LIEGT NICHT AM HOST AN!)
WAN-seitig eingehende Pakete (an eine definierte öffentliche IP) werden per DNAT an den betreffenden Host weitergeleitet.
+ Firewalling/Queueing läuft über Edge-Router
– private IP liegt am betreffenden Host an – kann zu Problemen führen, wenn die öffentlichen IP genutzt werden muss (Zertifikate…)
Nähere Beschreibung der Methode 2
Dazu werden das betreffende WAN-Interface und das LAN-seitige (zum betreffenden Host zeigende) Interface des Routers auf „Proxy-ARP“ gestellt (hier VLAN-WAN und VLAN-DMZ). Normalerweise befindet sich ein solcher Host in einer DMZ, zur Vereinfachung werden hier aber keine Sicherheitskonzepte von Dual/Multi-Homed-DMZ-Hosts aufgeführt.
Warum auf beiden Interfaces Proxy-ARP:
- WAN-Interface: Edge-Router antwortet auf ARP-Requests aus dem WAN, die den DMZ-Host* zum Ziel haben
- LAN-Interface: Edge-Router antwortet auf ARP-Requests des DMZ-Hosts, wenn diese das Default-Gateway** zum Ziel haben
* Die Ziel-IP muss exakt mit der IP des DMZ-Hosts übereinstimmen, das diese als /32 IP definiert ist.
** Es spielt keine Rolle ob das Default-Gateway korrekt auf dem DMZ-Host eingetragen wurde. Der Edge-Router wird immer auf den ARP-Request antworten, solange er über ein Route, die die IP des ARP-Requests einschließt, verfügt.
Hintergrundinfo: When a router replies to an ARP request for an IP address that does not belong to it but for which the router has a route in the routing table, the router is said to perform proxy ARP functionality. Quelle: Alex Zinin – Cisco IP Routing – Packet Forwarding and Intra-domain Routing Protocols
WAN zu LAN (DMZ):
LAN (DMZ) zu WAN:
Tipp: Proxy-ARP nach Möglichkeit sparsam einsetzen, da Fehlkonfigurationen dadurch leicht „verschleiert“ werden können! Cisco-Geräte haben oftmals Proxy-APR ab Werk eingeschalten, bei Mikrotik ist es standardmäßig ausgeschalten.
Sonderfall: LAN (DMZ) zu (V)LAN:
Bei Fällen in denen der DMZ-Host mit einem Host in/aus einem anderen LAN (VLAN) kommuniziert, muss die Antwort ebenfalls über das Gateway gesendet werden (Gateway = Edge-Router oder ISP-Router). Hierzu arbeitet der Edge-Router (jeder Router) nach dem Prinzip „Longest Prefix Match“. Die binäre (V)LAN-Ziel-IP weißt dabei eine größere Spezifität in der Routingtabelle mit dem Ziel-Netz (an das der Router selbst angeschlossen ist) auf, als das Default-Gateway (niedrigst mögliche Spezifität).
Hintergrundinfo: To resolve ambiguity that can arise when more than one entry matches a destination, Internet forwarding examines entries with the longest prefix first. Quelle: Douglas E. Comer – Computer Networks and Internets
[…] for a given destination which matches multiple network+mask pairs, the match with the longest mask is used. Quelle: RFC 1519
Auch in Fällen in denen mit Policy-Based-Routing (Mangle-Prerouting) gearbeitet wird.
Dieses findet in der Prerouting-Chain statt, die im Paketfluss vor der eigentlichen Routing-Entscheidung steht:
Als potenziell problematisch muss gesehen werden, dass es dabei zu einem asymmetrischen Routing kommen kann! Beispielsweise wenn der DMZ-Host aus einem (V)LAN Pakete erhält, in dem er selbst kein Interface hat. Die Antwort wird folglich über das Defaut-Gateway zurückgesendet. Allerdings nur, wenn der DMZ-Host asymmetrisches Routing (eingehendes Interface != ausgehendes Interface) zulässt. Microsoft hat seit Windows Vista/Server 2008 den „Next Generation TCP/IP Stack“ eingeführt, der standardmäßig das „Strong Host Model“ [RFC 1122] nutzt (kein asymmetrisches Routing erlaubt). Viele Enterprise-Linux-Distributionen nutzen den RPF „Mode 1“ (Strict Mode) [RFC 3704], der in etwa dem „Strong Host Model“ von Microsoft entspricht (kein asymmetrisches Routing erlaubt).
Umgangen kann diese Problematik auf drei Arten werden:
- ein dediziertes VLAN-Interface auf dem DMZ-Host für das entsprechende VLAN anlegen
- ein Router schreibt per SNAT die Quell-IP um, was den DMZ-Host dazu veranlasst, die Antwort nicht über das Gateway zurückzusenden
- je nach Host eine der folgenden Möglichkeiten:
- Windows-Systeme: Das „Weak Host Model“ nutzen (zumindest auf dem Gateway-Interface: „weakhostsend=enabled“).
- Linux-Systeme: Den RPF „Mode 0“ (No Source Address Validation) oder „Mode 2“ (Loose mode) nutzen.
Ausgangssituation:
- öffentlich nutzbare IPs: 100.100.100.10 bis 100.100.100.14
- Gateway: 100.100.100.9
/interface vlan set VLAN-DMZ arp=proxy-arp set VLAN-WAN arp=proxy-arp
Es wird angenommen, dass die IP-Adresskonfiguration von Interface VLAN-WAN schon durchgeführt wurde.
Ansonsten muss dies noch nachgeholt werden:
/ip address add address=100.100.100.10/29 interface=VLAN-WAN /ip route add distance=1 gateway=100.100.100.9
Nun muss noch die IP-Adresse des zum Host zeigenden Interfaces konfiguriert werden:
/ip address add address=100.100.100.10/32 interface=VLAN-DMZ network=100.100.100.11
WICHTIG: Die IP-Adresse hier mit „/32“ eintragen, das Netz (sollte es automatisch eingetragen werden) auf die IP des Hosts abändern! Dadurch wird eine Point-to-Point-Route erzeugt (ähnlich den P2P-Routen des Point-to-Multipoint Netzwerktyps von OSPF).
Auf dem Host nun als IP 100.100.100.11/29 und als Gateway 100.100.100.10 konfigurieren.
Für weitere Hosts kann das Ganze fortgeführt werden. Nur die Netzadresse (auf dem zum Host zeigenden) Interface des Routers ändert sich.
Anmerkung: Wer Policy-Based-Routing (beispielsweise bei Multi-WAN-Anbindungen) nutzt, muss u. U. noch eine zusätzliche Matching-Regel im Mangle-Tab definieren (im Beispiel: Routing-Mark zur WAN-Verbindung/100.100.100.10-Verbindung [der Router selbst hat kein Interface mit der IP 100.100.100.11]). Damit Traffic aus der DMZ/dem VLAN (LAN-seitige Quell-IP = öffentlichen IP [100.100.100.11]) auch der richtigen Routing-Tabelle zugewiesen wird! Ansonsten werden TCP-Verbindungen nie über den SYN-Status hinauskommen. Bei UDP, ICMP… schlägt asymmetrische Routing zu, wenn die Standard-WAN-Verbindung des Routers (in der Main-Routing-Table das Ziel mit der niedrigsten administrativen Distanz) nicht exakt der Proxy-ARP-WAN-Verbindung entspricht.
Beispiel: Asymmetrisches Routing (bedingt durch fehlende Routing-Mark):
Grundsätzlich könnte ein entsprechend „falsches“ IP-Paket problemlos geroutet werden. Allerdings spielt die jeweilige Implementierung des IP-Protokolls und die Konfiguration der nachfolgenden Router eine Rolle. Im konkreten Fall findet eine Quell-IP-Adressprüfung durch den ISP-Router statt, der nur Pakete einer einzigen IP akzeptiert. Aufgrund solcher Unbekannten sollte asymmetrisches Routing vermieden werden!
Beispiel: Korrektes (symmetrisches) Routing:
Zusammenfassung
Konfigurationsschema:
WAN zu LAN:
I/F2 antwortet auf ARP-Request von I/F1, weil der Router über eine Route [definiert per IP auf I/F3] zum Ziel [I/F4] (100.100.100.11) verfügt.
LAN zu WAN/(V)LAN:
I/F3 antwortet auf ARP-Request von I/F4, weil der Router über eine Route [definiert per IP auf I/F2] zum Ziel [I/F1] (100.100.100.9) verfügt.
Nun kann unter Angabe der öffentlichen IP jeder Dienst auf dem betreffenden Host WAN-seitig aufgerufen werden. Die Firewall bzw. das Queueing des Routers können (sollten) genutzt werden.
Dies stellt eine sehr elegante Methode dar, um den Vorteile des Routers mit der öffentlichen IP direkt auf dem Host kombinieren zu können.
Zur Funktionsweise von Proxy-ARP gibt es ein sehr gutes Video:
Im Video wird Proxy-ARP übrigens „umgedreht“ verwendet, die /32-IP auf dem WAN-seitigen Interface. Dies sollte in einfachen Topologien auch möglich sein, im Kontext des Policy-Based-Routings macht es aber mehr Sinn, auf dem WAN-seitigen Interface die „normale“ IP-Konfiguration zu nutzen und auf den LAN-seitigen DMZ/VLAN-Interfaces, nach Bedarf, die /32er. Beispielsweise wenn eine IP aus dem öffentlichen Pool per Proxy-ARP und eine andere IP per DNAT (oder PBR-Matchern) genutzt wird.
Systemadministrator
Informationstechnik – Netzwerktechnik – Consulting
MCSA+M | MCSE | MTCNA