Re: [exim] Proxy smtp connections to multiple Exim servers b…

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Sebastian Arcus
Dátum:  
Címzett: Andrew C Aitchison
CC: Exim Users
Tárgy: Re: [exim] Proxy smtp connections to multiple Exim servers behind proxy

On 15/04/2023 19:09, Andrew C Aitchison wrote:
> On Sat, 15 Apr 2023, Sebastian Arcus wrote:
>
>> On 15/04/2023 18:44, Andrew C Aitchison wrote:
>>> On Sat, 15 Apr 2023, Sebastian Arcus via Exim-users wrote:
>>>
>>>> I have a number of Exim servers behind a NAT gateway (actually
>>>> connected with vpn's to a cloud vps - but I'm hoping this is not
>>>> relevant to this post). I would like the gateway to send incoming
>>>> port 25 traffic to the correct Exim server based on SNI in incoming
>>>> TLS packets - as different Exim instances serve different email
>>>> domains. The setup would look like this:
>>>>
>>>>                      [Internet]
>>>>                          |
>>>>                          |
>>>>                    (smtp port 25)
>>>>                          |
>>>>                          v
>>>>                          |
>>>>                   [Cloud server]
>>>>                          |
>>>>                          v
>>>>                          |
>>>>       ----------------------------------------
>>>>       |                  |                   |
>>>>       |                  |                   |
>>>> [Exim server 1]    [Exim server 2]    [Exim server 3]
>>>>
>>>>
>>>> I would have preferred to do this at IP tables level - but
>>>> apparently not really possible. It seems the next option would be
>>>> HAProxy. Has anyone here used HAProxy or run a setup as above, or
>>>> know if this is actually doable? Any suggestions much appreciated.
>
>
>>> Since you have different domains, my first thought would just be to
>>> assign them different MXes with different IPs ...
>>
>> This is the situation now. But managing a full set of internet
>> connections with fixed IP addresses and reverse dns records is turning
>> into a major drag. Every time the internet connection on one of the
>> boxes has to change provider, it becomes a whole project managing the
>> migration, with downtime while the provider assigns a PTR record to
>> the connection. On occasion it has taken 2 weeks. This is why I would
>> like to have all boxes use one single public IP address and one PTR
>> record through the VPS / cloud server for smtp purposes, with the VPS
>> acting as a SMTP proxy / gateway.
>
> Ah.
>
> I've only done it with physical local machines, where
> it was easy to move an ip address from one box to another.
> I had an ip address for each box and one for each domain,
> so I could just move the domain ip address to another machine
> when necessary. No need to change the DNS at all.
> Not necessarily something you can do with a cloud.


Sorry - I tried to keep the original question as simple as possible,
hoping that would make it easier to answer.

The "back-end" machines are physical machines, on regular
ADSL/VDSL/cable/fibre connections at various locations. At the moment
they send directly to the internet, which requires a static IP and PTR
record. The PTR record needs to be requested from the provider of the
internet connection. This process has taken in the past anywhere between
3-14 days - depending on provider and luck finding a member of staff who
knows what a PTR record is.

It also restricts the choice of internet providers to those who do
provide PTR records. Also, if there is a fault with the internet
connection and it gets replaced with a temporary (4G/5G) connection, the
server effectively can't send and receive emails any more - for days or,
worse case scenario, weeks at a time.

To solve all of the above issues, I am looking into essentially
diverting all the outgoing and incoming smtp traffic of these servers
through a single gateway server, which will be a vps/cloud server. Then
the flow of emails on smtp will be able to continue uninterrupted, even
when changing internet providers at various locations where the back-end
servers are, or switching to an emergency/temporary internet connection.

I hope the above makes a bit more sense.