This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SMTP Uplinkmultipath

Hallo,

wir haben 2 WAN Verbindungen, eine 20 Mbit Telekom und eine 6 Mbit anderer Provider. Derzeit betreibe ich beide per Uplink Multipath.

Multipathregeln:
Any -> DNS -> Any -> by connection
Any -> SMTP -> Any -> by Interface anderer Provider
Any -> Any -> Any -> by Interface Telekom

Wir benutzen den SMTP Proxy. Wir schicken unsere Mails über einen Smarthost an den anderen Provider raus, da der auch unseren MX-Record hat und uns die Mails Weiterleitet normal.

Jetzt hatten wir das Problem das die Leitung von dem anderen Provider down war. Dadurch hat die Astaro versucht die Emails über die Telekom Leitung abzuschicken. Da der Smarthost aber keine Authentifizierung hat, werden die Mails abgewiesen mit Relay Access Denied, was ja auch verständlich ist.

Meine Gedanken waren jetzt:
1. Den Smarthost wegzulassen weil unsere IP einen DNS Namen hat und RDNS eingerichtet ist beim Provider?
2. Was passiert wenn ich dem Smarthost die Schnittstelle von Uplink Interface auf das Interface von dem anderen Provider änder? Muss man dann ggf. noch eine SNAT-Regel für das WAN Interface für SMTP erstellen?

Ich weiß ja nicht ob man mischen kann zwischen Uplink Interface und normalen WAN Interface? Oder ob man dann nur noch Uplink Interface nutzen kann. 

Kann man dem direkt einem Uplink Multipath Interface sagen, das nur SMTP über die eine Schnittstelle geht, auch wenn die Schnittstelle down ist? So das er es für SMTP garnicht erst über die andere Schnittstelle versucht.

Ich hoffe es ist halbwegs verständlich...und hoffe ihr könnt mir helfen.

Gruß Linde


This thread was automatically locked due to age.
  • Hallo Linde,

    ich habe dafür eine Lösung, da ich auch im November vor diesem Problem stand.
    Ich kann sie leider gerade nicht posten, da ich beschäftigt bin, nehme mir aber heute Abend dann die Zeit zu erklären, wie ich das Problem umschifft habe.
    Nur vorab, es gibt keine einfache "Häkchen an/aus" Lösung, da Astaro diesen Fall nicht in ihrer Konfig bedacht hat. (Gilt nur bis Version 9.1)
  • Edit: Dieser Lösungsweg gilt bis einschließlich Version 9.1! (Neuer Weg, siehe unten im neuen Post)

    Leider hatte ich gestern keine Zeit mehr, nun aber hier mein Lösungsansatz.

    Eine kurze Zusammenfassung des (bei mir vorhandenen) Problems:
     
    Es gibt 2 WAN-Schnittstellen:
    Kabelinternet zum Surfen
    TDSL-Einwahl als Backupleitung, außerdem für Mail mit fester IP
    Es ist Uplinkbalancing eingerichtet mit Multipfadregeln.
    1. Schnittstelle ist Kabelinternet
    2. Schnittstelle ist TDSL mit Weight 0, um Loadbalancing zu verhindern

    Multipfad Surfen wird aus Kabelinternet geschickt
    Multipfad SMTP wird aus TDSL geschickt.

    Das funktioniert solange beide Leitungen UP sind oder nur Kabelinternet Down.
    Probleme gibt es, wenn TDSL down ist, da dann SMTP über Kabelinternet läuft. 
     
    Verschiedene Lösungsansätze haben nicht zum gewünschten Ergebnis geführt:
    Drop-Firewallregel funktioniert nicht, da die automatischen Regeln vor den Userregeln kommen
    Policy-Routing funktioniert nicht, da kein festes Gateway vorhanden (Einwahlverbindung)
    SNAT funktioniert nicht, da Regel nicht angelegt wird, wenn Interface nicht da ist
    Blackholeroute alleine stehend funktioniert nicht, da  nicht auf Interface bindbar.
    Diverse andere Versuchsansätze scheiterten schon direkt bei der Überlegung aufgrund der nicht vorhandenen Einstellmöglichkeit im WebAdmin
    Lösung:
    Bei der Blackholeroute jedoch hab ich mich festgebissen und eine brauchbare Lösung gefunden:
     
    Zunächst erstelle ich eine DNAT-Regel, die auf dem KabelWAN-Interface die SMTP-Pakete matched und auf eine nicht benutzte Adresse (ich nenne sie mal Blackhole-Adresse) NATed.
     
    Dann sende ich die Datenpakete an diese Blackhole-Adresse per Blackhole-Route ins Nirvana.
    Bedeutet, dass der SMTP-Server einen temporären Fehler bekommt, damit die ausgehenden Mails in der Queue belässt.
     
    Nachdem die Leitung wieder da ist, dauert es meist noch 5 Minuten, bis die Pakete auch wirklich nicht mehr über das Kabel-Interface hinauswollen, das liegt aber denke ich an der Dynamik beim Umschalten des Uploadbalancings und/oder einem Connectiontracking, bis da alle Pakete wieder zum richtigen Interface herausgesendet werden.

    Zusatzinformation:
    Wenn auf beiden Internetleitungen feste IPs mit festen Gateways vorhanden sind. kann man hier auch das selbe Ergebnis mit Policyrouten erreichen.

    Ich hoffe das ist soweit verständlich, da der Text selbst ursprünglich an den Astaro-Support gerichtet war und ich hier natürlich schon im Dialog stand, soll heißen, der Umstand selbst schon bekannt war.
    Wenn es noch Unklarheiten zu beseitigen gilt, einfach fragen [;)]
  • Aktuell kannst Du ffür die Mailservices eine SNAT rule erstellen, welche smtp, smtp/ s usw. ausgehend auf die fixe IP des DSL Links ändert. Source bei der SNAT rule muss ANY sein, damit der SMTP Proxy, bzw. jedes aktive uplink Interface eingeschlossen ist. 

    Damit gehen die mails dann nur via DSL raus, weil die DSL IP als Absender beim Kabelmodem nicht geroutet werden kann...

    Ist so an diversen Orten im Einsatz ;o)

    gruss Sascha

    Wer Schreibfehler findet, darf sie behalten. Wenn ich via IPad poste, sind Verschreiber und grammatikalische Aussetzer irgendwie an der Tagesordnung.
  • Ab der Version 9.2 gibt es eine einfache Möglichkeit, die Bindung für SMTP bei Multipathing zu erreichen.

    Hierzu muss man nur in den Erweiteren Einstellungen der Multipathregel für SMTP das Häkchen entfernen bei "Diese Regel bei Schnittstellenfehler überspringen".

    Das bewirkt, dass kein Linkausgleich für das SMTP-Protokoll gemacht wird und somit auch nicht aus der falschen Schnittstelle gesendet wird.
  • Ab der Version 9.2 gibt es eine einfache Möglichkeit, die Bindung für SMTP bei Multipathing zu erreichen.

    Hierzu muss man nur in den Erweiteren Einstellungen der Multipathregel für SMTP das Häkchen entfernen bei "Diese Regel bei Schnittstellenfehler überspringen".

    Das bewirkt, dass kein Linkausgleich für das SMTP-Protokoll gemacht wird und somit auch nicht aus der falschen Schnittstelle gesendet wird.


    Das ist falsch, diese Möglichkeit hast du bereits jetzt schon, mit der Version 9.1

    Haken ist per Default aktiv --> somit wird über Leitung B gesendet, wenn Leitung A ausfällt
    Haken raus --> nur Leitung A wird verwendet

    Was man aktuell noch nicht kann, Multiple Hostnames, dafür gibt es nen Feature Request:
    http://feature.astaro.com/forums/17359-utm-formerly-asg-feature-requests/suggestions/178318-smtp-multiple-hostnames-interfaces-support

    Nice greetings