\n\n![\"small](\"https:\/\/blog.iwen.de\/wp-content\/uploads\/2009\/03\/smallsitemultihoming1.png\" "\\"small") <\/td>\n<\/tr>\n<\/table>\nDort ist das Problem des asymmetrischen Traffics etwas aufwendiger zu l\u00f6sen.
\nWie in dem Dokument Servers in Small Site Multi-homing<\/em> beschrieben, hat der Server zwei zus\u00e4tzliche IP-Adressen, f\u00fcr die auf den zwei Routern jeweils ein statischer NAT-Eintrag vorhanden ist.<\/p>\nWenn man f\u00fcr den Server annimmt, da\u00df dieser f\u00fcr das Mail-Handling zust\u00e4ndig ist, dann muss man annehmen, da\u00df \u00fcber beide ISPs Mails eingeliefert werden, egal ob der MX mit der h\u00f6heren Priorit\u00e4t erreichbar ist oder nicht.<\/p>\n Die Grundkonfig der Router k\u00f6nnte folgenderma\u00dfen aussehen (anstelle des Intrerface-Trakings k\u00f6nnte man besser auch “ip sla” verwenden):<\/p>\n hostname R1\n!\ninterface FastEthernet0\/0\n ip address 10.10.10.1 255.255.255.0\n ip nat inside\n standby 0 ip 10.10.10.3\n standby 0 priority 105\n standby 0 preempt\n standby 0 track FastEthernet0\/1\n!\ninterface FastEthernet0\/1\n ip address 192.168.1.1 255.255.255.0\n ip nat outside\n!\nip nat pool ISP-A-POOL 192.168.1.11 192.168.1.11 prefix-length 24\nip nat inside source list INSIDE-HOSTS pool ISP-A-POOL overload\nip nat inside source static 10.10.10.101 192.168.1.101 extendable\n!\nip access-list standard INSIDE-HOSTS\n permit 10.10.10.0 0.0.0.255\n<\/code><\/pre>\n\nhostname R2\n!\ninterface FastEthernet0\/0\n ip address 10.10.10.2 255.255.255.0\n ip nat inside\n standby 0 ip 10.10.10.3\n standby 0 preempt\n!\ninterface FastEthernet0\/1\n ip address 192.168.2.1 255.255.255.0\n ip nat outside\n!\nip nat pool ISP-B-POOL 192.168.2.12 192.168.2.12 prefix-length 24\nip nat inside source list INSIDE-HOSTS pool ISP-B-POOL overload\nip nat inside source static 10.10.10.102 192.168.2.102 extendable\n!\nip access-list standard INSIDE-HOSTS\n permit 10.10.10.0 0.0.0.255\n<\/code><\/pre>\nDer Traffic flie\u00dft hier folgenderma\u00dfen:<\/p>\n \n\n\n\n![\"small](\"https:\/\/blog.iwen.de\/wp-content\/uploads\/2009\/03\/smallsitemultihoming2.png\" "\\"small") <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n- Vom Server ausgehender Traffic (schwarz) flie\u00dft zum aktiven HSRP-Router und bekommt eine Adresse aus dem ISP-A-POOL.<\/li>\n
- Von au\u00dfen initiierter Traffic auf die 192.168.1.101 (gr\u00fcn) flie\u00dft \u00fcber den aktiven Router zur\u00fcck und NAT l\u00e4uft wie erwartet.<\/li>\n
- Von aussen initiierter Traffic auf die 192.168.2.102 (rot) flie\u00dft ebenfalls \u00fcber den aktiven Router zur\u00fcck. NAT behandelt diesen Traffic wie vom Server ausgehenden Traffic und das Antwort-Paket bekommt ebenfalls eine Absender-Adresse aus dem ISP-A-POOL, mit der der Client nichts anfangen kann.<\/li>\n<\/ul>\n
Auf dem Switch PBR zu konfigurieren ist aufgrund der PBR-Implementierung vermutlich keine Option (3750: nur auf routed Interface oder SVI, IP Services Image, kein PBR bei gemeinsamen IPv4 und IPv6).
\nAuf dem Server die Konfiguration vorzunehmen ist evtl. auch nicht m\u00f6glich oder gewollt.
\nAuf dem Router R1 ist es allerdings relativ einfach umzusetzen:<\/p>\n ip access-list extended TRAFFIC-FROM-102\n permit ip host 10.10.10.102 any\n!\nroute-map POLICY-INSIDE-IN permit 10\n match ip address TRAFFIC-FROM-102\n set ip next-hop 10.10.10.2\n!\ninterface FastEthernet0\/0\n ip policy route-map POLICY-INSIDE-IN<\/code><\/pre>\nJetzt ergibt sich der Traffic-Flu\u00df wie es gew\u00fcnscht ist:<\/p>\n \n\n\n\n![\"small](\"https:\/\/blog.iwen.de\/wp-content\/uploads\/2009\/03\/smallsitemultihoming3.png\" "\\"small") <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nJetzt kommt nat\u00fcrlich noch die IOS-Firewall und eingehende ACLs auf beiden Interfaces hinzu.
\nDaf\u00fcr muss die Konfiguration noch etwas erweitert werden. Zum einen m\u00fcssen sowohl eingehende, als auch ausgehende Antwortpakete per Inspection erlaubt werden, da die ACLs ein abschlie\u00dfendes deny any<\/em> haben sollten. Zum anderen muss der Traffic, der per PBR umgeroutet wird, auch in der ACL erlaubt werden, da die ACL vor dem Policy-Based Routing abgearbeitet wird (hier k\u00f6nnte man nat\u00fcrlich zwischen einer aus- und eingehenden FW-Policy unterscheiden):<\/p>\nip inspect name FW tcp router-traffic\nip inspect name FW udp router-traffic\nip inspect name FW icmp router-traffic\n!\ninterface FastEthernet0\/0\n ip access-group INSIDE-IN in\n ip inspect FW out\n!\ninterface FastEthernet0\/1\n ip access-group OUTSIDE-IN in\n ip inspect FW out\n!\nip access-list extended INSIDE-IN\n permit ip host 10.10.10.102 any\n !permit whatever you want\nip access-list extended OUTSIDE-IN\n permit tcp any host 192.168.1.101 eq smtp<\/code><\/pre>\nAbschlie\u00dfend nat\u00fcrlich noch der Hinweis, da\u00df dieser Server sinnvollerweise als Mail-Relay in der DMZ implementiert sein sollte. Der “richtige” Mail-Server steht dann intern und bekommt seine Mails von dem Relay.<\/p>\n","protected":false},"excerpt":{"rendered":" Ivan Pepelnjak hat in seinen sehr lesenswerten Artikeln Small Site Multi-homing, Redundant Small Site Multi-homing und Servers in Small Site Multi-homing sehr sch\u00f6n beschrieben, wie man sich als kleiner Kunde mit mehreren Providern verbinden kann. Eine sehr wichtige Topologie fehlt allerdings: Wie implementiert man Server, wenn man mit zwei Routern an unterschiedlichen ISPs angeschlossen ist: <\/p>\n continue reading<\/a><\/div>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"twitterCardType":"","cardImageID":0,"cardImage":"","cardTitle":"","cardDesc":"","cardImageAlt":"","cardPlayer":"","cardPlayerWidth":0,"cardPlayerHeight":0,"cardPlayerStream":"","cardPlayerCodec":"","footnotes":""},"categories":[5,14],"tags":[307,358,418],"class_list":["post-1192","post","type-post","status-publish","format-standard","hentry","category-cisco","category-networking","tag-ios","tag-konfiguration","tag-multihoming"],"_links":{"self":[{"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/posts\/1192","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/comments?post=1192"}],"version-history":[{"count":0,"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/posts\/1192\/revisions"}],"wp:attachment":[{"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/media?parent=1192"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/categories?post=1192"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cyber-fi.net\/index.php\/wp-json\/wp\/v2\/tags?post=1192"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
|
|
|