F5 BIG-IP som utgående proxy för massutskick av e-post: persistens, SNAT, timeouter och DNS-upplösning

En faktureringskörning eller ett nyhetsbrevsutskick med omkring 1 000 e-postmeddelanden per minut lämnar företagsnätverket, med en F5 BIG-IP som utgående proxy till leverantörens inlämningspunkt däremellan. BIG-IP belastningsfördelar inte mellan flera mål, utan vidarebefordrar trafiken. Just denna konstellation avgör vilka inställningar som är meningsfulla och vilka påstådda optimeringar som inte ger någon effekt.

Arkitekturen i en mening

Utskicksystemen använder en intern Virtual Server-adress på BIG-IP som Smarthost, BIG-IP översätter avsändaradresserna via SNAT till en fast offentlig IP-adress och vidarebefordrar varje anslutning till leverantörens värdnamn. Load Balancing i egentlig mening sker inte på BIG-IP, eftersom poolen bara har en medlem. Det låter som en trivial konfiguration, men detaljbesluten (persistens, timeouter, SNAT-typ, DNS-upplösning) avgör om utskicken fungerar stabilt eller uppvisar oförklarliga avbrott under belastning.

Är Sticky Sessions bättre? Nej, av två skäl

Frågan om sessionspersistens kommer från HTTP-världen, där en användare med kundvagn eller inloggningssession alltid måste hamna på samma backend. Överfört till SMTP saknar konceptet mening.

För det första avslutas SMTP tillståndslöst per anslutning: Varje anslutning hanterar en eller flera fullständiga transaktioner (MAIL FROM, RCPT TO, DATA) och avslutas med QUIT. Det finns inget tillstånd som måste ligga kvar på samma målsystem mellan anslutningar. Vilket system på leverantörssidan som accepterar nästa anslutning saknar betydelse för leveransen.

För det andra finns det helt enkelt inget att persistera på denna BIG-IP: Poolen innehåller exakt en medlem, leverantörens enda IP-adress. En persistensprofil skulle bara förbruka minne för en persistens-tabell och kosta en uppslagning vid varje anslutning, som alltid ger samma resultat. Rätt inställning är därför: Default Persistence Profile på None. Även om leverantören senare skulle publicera flera IP-adresser bakom värdnamnet vore persistens kontraproduktivt, eftersom den skulle förhindra fördelningen över dessa adresser och belasta enskilda mål ensidigt.

Avgörande för genomströmningen vid massutskick är avsändarens anslutningsprofil: få långlivade anslutningar med många meddelanden per anslutning i stället för en ny anslutning per e-postmeddelande; mer om detta längre ned.

Virtual Server: FastL4 i stället för Full Proxy

För ren vidarebefordran av SMTP är en Performance-(Layer 4)-Virtual Server med FastL4-profil rätt val. BIG-IP behandlar då anslutningen till stor del i hårdvara eller i den accelererade sökvägen, utan att terminera TCP-anslutningen fullständigt. En standard-Virtual Server i Full Proxy-läge ger bara ett mervärde om du faktiskt vill ingripa i dataströmmen på BIG-IP, till exempel med en SMTP-säkerhetsprofil eller iRules på protokollnivå. För en Outbound Proxy till den egna avtalsleverantören är detta onödigt och skapar bara ytterligare felkällor.

Viktigt i båda fallen: aktivera ingen profil som skriver in i anslutningen. STARTTLS förhandlas direkt mellan utskicksystemen och leverantörens relä; varje instans som ändrar eller filtrerar byte äventyrar TLS-etableringen.

DNS-upplösning: leverantörens värdnamn ska finnas som FQDN-nod i poolen

Leverantören har lämnat ett värdnamn, inte en IP-adress. Den närliggande reflexen att lösa upp IP-adressen en gång och registrera den statiskt som en nod är den sämsta varianten: Om leverantören byter adress (underhåll, flytt, DR-fall) stannar utskicket tills någon anpassar BIG-IP-konfigurationen. Det är precis därför FQDN-noder finns.

En FQDN-nod lagrar värdnamnet i stället för adressen. BIG-IP löser själv upp namnet, skapar en så kallad Ephemeral Node för varje returnerad adress och uppdaterar dessa automatiskt när DNS-svaret ändras. Som standard frågar den namnet igen när DNS-TTL har löpt ut; alternativt kan ett fast frågeintervall anges. Med Autopopulate aktiverat tar poolen även automatiskt emot flera A-records som medlemmar: Om leverantören senare utökar sin inlämning till flera adresser följer BIG-IP med utan någon konfigurationsändring.

Två förutsättningar glöms ofta bort. För det första behöver BIG-IP fungerande DNS-servrar i systemkonfigurationen (System, Configuration, Device, DNS); FQDN-noder använder systemets resolvers, inte någon DNS-cache från en Listener-profil. För det andra bör dessa resolvers faktiskt vara nåbara från management- respektive TMM-kontexten, annars förblir noden i status unresolved och poolen tom.

Konfigurationen i tmsh ser ut så här (adresser och namn är exempel):

tmsh create ltm node relay-provider fqdn { \
  name mail-relay.provider.example autopopulate enabled }

tmsh create ltm pool pool_provider_smtp \
  members add { relay-provider:25 } monitor tcp

tmsh create ltm snatpool snat_mailout \
  members add { 198.51.100.10 }

tmsh create ltm virtual vs_mailout_smtp \
  destination 10.0.5.10:25 ip-protocol tcp \
  profiles add { fastL4 } pool pool_provider_smtp \
  source-address-translation { type snat pool snat_mailout }

Utskicksystemen anger därefter 10.0.5.10 som Smarthost. Om du använder port 25 eller 587 bestäms av leverantören; BIG-IP-konfigurationen är identisk i båda fallen, endast porten ändras.

SNAT: fast adress i stället för Automap

För utgående e-posttrafik måste källadressen vara under kontroll. SNAT Automap använder den flytande Self-IP-adressen för det utgående VLAN:et, och den kan ändras obemärkt vid nätverksändringar eller failover-ombyggnader. Leverantörer kopplar dock ofta inlämning till IP-allowlisting, och även utan formell allowlisting är ryktet knutet till källadressen. En dedikerad SNAT-pool med en fast tilldelad adress gör käll-IP:n till ett dokumenterat, stabilt konfigurationsobjekt.

När det gäller kapacitet: En enda SNAT-adress erbjuder cirka 64 000 samtidiga översättningar mot ett enda mål (en IP, en port), eftersom varje anslutning får en egen ephemeral källport. Med den belastningsprofil som beskrivs här, med några dussin samtidiga anslutningar, är det mer än tillräckligt. Portutarmning blir först ett problem när en felkonfigurerad avsändare öppnar en ny anslutning per e-postmeddelande och inte stänger den korrekt; då samlas översättningar i ett TIME-WAIT-liknande tillstånd. Ett sådant beteende åtgärdas hos avsändaren, inte med en andra SNAT-adress.

Timeouter: den vanligaste orsaken till anslutningsavbrott under belastning

En bulkavsändare håller anslutningar öppna och skickar meddelande efter meddelande. Mellan två meddelanden kan pauser uppstå: Avsändaren genererar nästa block, reläet fördröjer godkännandet (Tarpitting, rester av Greylisting, interna köer). Idle-timeouten i FastL4-profilen är som standard 300 sekunder. Om en paus är längre rensar BIG-IP bort anslutningen, och avsändaren skriver till en anslutning som inte längre finns.

Två inställningar mildrar detta. För det första ska Idle-timeouten sättas till ett värde som överstiger realistiska pauser; för massutskick är 600 sekunder ett rimligt startvärde. Värdet bör inte vara godtyckligt högt, eftersom övergivna anslutningar annars samlas i anslutningstabellen. För det andra ska Reset on Timeout förbli aktiverat i profilen: BIG-IP bekräftar då rensningen med en TCP-reset, och den sändande MTA:n upptäcker omedelbart att anslutningen är borta, i stället för att hamna i en timeout och schemalägga om meddelandet först efter flera minuter.

Du har ingen påverkan på motpartens timeouter, men de ingår i helhetsbilden: Om leverantörens relä stänger anslutningar efter 120 sekunders inaktivitet hjälper inte en generös BIG-IP-timeout. Det minsta timeout-värdet längs hela vägen är avgörande; fråga vid tvekan leverantören och använd detta värde som planeringsunderlag.

Anslutningsstrategi: få anslutningar, många meddelanden

Utan inlämningskrav från leverantören är en kort beräkning värdefull. 1 000 e-postmeddelanden per minut motsvarar cirka 17 per sekund. En SMTP-transaktion över en redan etablerad anslutning tar vid normal latens betydligt mindre än en halv sekund. Med 10 till 20 parallella anslutningar och exempelvis 100 meddelanden per anslutning innan avsändaren förnyar dem uppnås målhastigheten utan problem. På leverantörssidan finns normalt betydligt större anslutningskapacitet, men den delas med alla andra kunder. Få långlivade anslutningar med många transaktioner är därför inte bara effektivt (TCP- och TLS-etableringen bortfaller per meddelande), utan också det mest skonsamma sättet att använda andras infrastruktur.

Reglagen för detta finns i utskicksystemet, inte på BIG-IP: maximalt antal meddelanden per anslutning, maximalt antal parallella anslutningar till Smarthost och återanvändning av etablerade anslutningar. På BIG-IP kan helheten säkras med ett Connection Limit på poolmedlemmen, exempelvis 200 samtidiga anslutningar: Vid normal drift nås värdet aldrig, men en felkonfigurerad avsändare som plötsligt öppnar en anslutning per e-postmeddelande översvämmar då inte leverantörens relä obegränsat. Gränsen är ett skyddsnät, inte ett styrinstrument.

Mätningen visar om den inställda anslutningsprofilen också fungerar i praktiken: Anslutningar per minut och meddelanden per anslutning kan utvärderas från Message Tracking eller Connector-loggarna, enligt artikeln Fastställ en e-postservers belastningsprofil beskriver. För ett belastningstest med en realistisk bulkbelastningsprofil (få sessioner, många meddelanden per session) passar smtp-source från Postfix-paketet bättre än HTTP-orienterade belastningsverktyg, eftersom det skapar just denna anslutningsprofil.

Övervakning: belasta inte leverantören med hälsokontroller

En monitor på poolmedlemmen är meningsfull, så att BIG-IP upptäcker ett avbrott på leverantörssidan och rapporterar det korrekt. Följande gäller dock: Varje healthcheck är en verklig anslutning till leverantören och räknas där mot samma gränser som nyttotrafiken. En enkel TCP-monitor med måttligt intervall (30 sekunder eller mer) räcker gott. En fullständig SMTP-monitor som kontrollerar ända till bannern eller EHLO ger knappt någon ytterligare insikt, men skapar loggposter hos leverantören och i värsta fall frågor om varför en anslutning utan e-post kommer in var femte sekund.

Checklista

Det korta svaret på den ursprungliga frågan är alltså: Nej, Sticky Sessions är inte bättre, de är i denna konstellation verkningslösa eller skadliga. Lösningens kvalitet avgörs av DNS-upplösningen av leverantörens värdnamn, av en stabil SNAT-adress, av timeouter som passar belastningsprofilen och av att utskicksystemen lämnar in sina 1 000 e-postmeddelanden per minut över få etablerade anslutningar i stället för över tusen enskilda.