Tartalék internet kapcsolat DNS és MX rekord beállítás

Hálózatok általános

Sziasztok,

Egy probléma megoldásában szeretnék kérni a hozzáértők segítségét.

Az alaphelyzet az, hogy az elsődleges internet kapcsolatunk kiesése esetére szeretnénk egy tartalék másodlagos kapcsolatot beüzemelni (failover megoldással). A tartalék internet egy fix ips 3G mobilnet. A routeren be is van már konfigurálva a failover, működik az átváltás.

Szeretnénk megoldani a levelezés zavartalanságát a tartalék vonalon is. A következőre gondoltam. A saját domainünkbe .hu felveszünk egy bejegyzést a tartalék kapcsolatunk fix ip-jére, legyen mondjuk mail2..hu, és ezt beállítjuk alacsonyabb prioritással az MX rekordba. Ezzel elvileg a bejövő emailek megoldódnak.

Másik irány a kimenő levelek, itt még ha jól sejtem szükség lenne a fix ip-hez tartozó rev. dns beállításához is (hogy ne akadjunk fel spam szűrőkön), ami az ip tartományt szolgáltató internet szolgáltatónál kell, ugye?
Mire állítsuk a rev.dns-t? Az én tippem a mail..hu lenne, hogy egyezzen a mail szerver nevével. Viszont itt már nem fog egyezni a sima és a rev. bejegyzés.

Mi a jó megoldás ebben az esetben, hogy a spam és mindenféle szűrőn sem kifelé, sem befelé ne akadjon el a levelezésünk?

Köszönöm előre is.

  • 6161 megtekintés

( janoszen v | 2014. 06. 13., p – 09:15 )

A levelezes pont olyan, hogy ha nem megy a net, akkor majd ujra probalkozik a kuldo szerver amikor visszajon. Egyebkent azt nem javaslom, hogy levelezo szervert uzemeltessetek a sajat telephelyeteken, az nem szokott jol elsulni, helyette inkabb egy szerverkozpontba allitsatok be gepet. A mobilnet kapcsolatnal PLANE.

Amennyiben megis ezzel a megoldassal eltek, akkor figyelni kell a kovetkezokre:

- Konzisztens A es PTR rekordok mindket vonalra. (mail.domained.hu -> 123.123.123.123 -> mail.domained.hu)
- A PTR rekord ne ugy nezzen ki, mint egy IP cim (pool-123-123-123-123.szolgaltato.hu), hanem rendes domain legyen.
- Az SPF rekordokban legyen engedelyezve mindket kapcsolat cime.
- Eroteljesen javallott a DKIM es a DMARC bevezetese.

Ja es arra figyelj, hogy tok mindegy, hogy mi a reverse DNS-ed, a vegfelhasznaloknak kiosztott szolgaltatoi cimtartomanyok sok helyen fent vannak blacklisten. Ha ilyet tapasztalsz, akkor semmi mas valasztasod nincs, mint egy hosting centrumban berelni / bevinni gepet vagy smarthostot hasznalni.

--
Pásztor János
Üzemeltető Macik

annyival kiegészíteném - hogyha mégis saját mailservert akartok üzemeltetni, akkor
- használj VPS-t ami fogadja a levelet és továbbdobja, ill. smarthost-ként működik a két FIX ipre
- bízd meg a szolgáltatót, hogy fogadja a domain.hu levelet és legyen smarthost neked.
vagy automatikusan továbbítja, vagy ETRN-el le tudod kérni tőle a queue-t.

ps: a hosting centrumban is sokat spammelnek a VPS-ek...

( Zs | 2014. 06. 13., p – 10:24 )

Ha ragaszkodsz ehhez a felálláshoz, akkor az a következő módon valósítható meg:
- a mail szerverre is két IP címet húzol fel a belső hálóban
- a gw/router/tűzfal attól függően, hogy melyik lábán jön az SMTP kapcsolat, a mail server vagy egyik, vagy másik IP-jére tolja be a kérést
- a gw/router/tűzfal attól függően, hogy a mail server melyik IP-jéről indul kifelé az SMTP kapcsolat, fixen vagy az egyik, vagy a másik külső valós IP-re NAT-olja a kapcsolatot
- innen kezdve már csak az MTA-t kell felokosítani, hogy attól függően, hogy melyik IP jön be vagy megy ki a kapcsolat, más-más néven mutatkozzon be vagy köszönjön. Korábban postfix kapcsán arra jutottam, hogy ott a kimenő IP alapján nem tudom rábeszélni más név használatára, de bejövő esetén simán megoldható az eltérő név használata - exim esetén viszont gond nélkül megoldható mindkét feladat.

Nálam ez a probléma úgy merült fel, hogy egy mail server több domaint is kiszolgál, a gépnek több IP címe is van - a kihívás pedig az volt, hogy az "A, B, C" domainek az 1. IP-n forgalmazzanak, a "D, E" domainek pedig a 2. IP-n. Ennek megfelelően a mail szervernek két valós IP-je is van (saját névvel, jó PTR rekorddal és persze az MX rekordok is jól beállítva), majd attól függően, hogy melyik IP-n hívnak rá, az ahhoz az IP-hez tartozó névvel üdvözli a klienst - illetve kimenő levél esetén a feladó domain-part alapján eldönti, hogy melyik interface-t, pontosabban melyik IP-t használja küldéshez és ennek megfelelően más-más néven mutatkozik be az EHLO parancsban.

Nálad a problémát nem ez jelenti, hanem hogy failover esetén változik az IP. Ennek megfelelően amire még szükség lenne:
- a gw/router/tűzfal failover scriptje jellezze a mail serveren, hogy aktuálisan melyik az aktív, használatban lévő kapcsolat (kulcsos ssh esetén egyetlen scp-vel megoldható )
- az én megoldásomban az MTA a feladó domain-part alapján választott forrás IP-t - nálad viszont a gw/router/tűzfal-tól megkapott "aktuális kapcsolat" alapján kell majd a forrás IP-t választani

" az MTA-t kell felokosítani, hogy attól függően, hogy melyik IP jön be vagy megy ki a kapcsolat, más-más néven mutatkozzon be vagy köszönjön."

Ez a lényeg, ez maradt ki a korábbi válaszokból, pedig az egyik legfontosabb. De nem egyszerű egy nat-olt hálón, amikor a levelező nem értesül róla, hogy mondjuk a dual-wan router átváltott a backup vonalra. (értesülnie kell)

Igen, valóban ezen van a hangsúly. A második blokkba azt írtam le, hogy nálam milyen feltételek mellett volt nekem szükség erre és hogy sikeresen meg is oldottam a feladatot - tehát az megoldható, van működő konfig rá.
Amit te írsz, hogy a levelezőnek értesülnie kell arról, hogy a NAT-olt hálón változik a default gw külső IP-je, miből normál esetben semmit nem vesz észre a kliens, igaz. Ezt a harmadik blokkban írtam le: "a gw/router/tűzfal failover scriptje jellezze a mail serveren, hogy aktuálisan melyik az aktív, használatban lévő kapcsolat". Ha a failover script egy kulcsos ssh belépéssel a váltás tényét jelzi a mailserver felé, akkor ez a probléma is orvosolva van.
Ok, lehet abba az irányba is menni, hogy mi van akkor, ha a mail server épp állt, amikor a váltás történt? Erre megoldás lehet, hogy a mail server a boot során lekérdezi, hogy melyik az aktuális külső IP.

( athila v | 2014. 06. 13., p – 17:04 )

Vagy kérsz egy /24-et és BGP-n hirdeted két külön ISP felé. Persze drága, de ezen kívül nem neveznék backupnak egyetlen eddig felsorolt hákolást se... :)

Leszállva a földre, azonos ISP-től kérsz backup vonalat és egy kisebb route-olt publikus tartománnyal majd ők megoldják a tartalékolást.

backup-ot azért illik szándékosan másik ISP-től kérni, mert csúnyán néz ki amikor mindkettő egyszerre hasal el, mert gáz van az ISP-nél.

Egyik helyen mikro-s fővonal, adsl-es backup1 és biztos ami biztos alapon egy usb-s HSDPA modem is backup2-nek a routerbe. Mindhárom különböző ISP, olyan még nem volt, hogy mindhárom egyszerre haljon el :)

Látott már olyat a világ, hogy A - B között drótot nem lehetett kihúzni, így maradt a mikrohullám, az egyik szolgáltató lerakott egy pár 2x2Mbit-es mikrót, egyik "kétmegát" eladta az üf.-nek, a másikat meg egy másik szolgáltatónak. Az üf. meg csodálkozott, hogy az éles és a backup vonala is egyszerre áll le karbantartás miatt :-P

Hasonló a helyzet nálunk is, csak még rosszabb kivitelben. Egy - viszonylag gyenge rendelkezésre állást biztosító - mikrohullámú szolgáltató érhető el, amely mellett még egy mobilnet is szóbajöhet tartaléknak. De egyetértek, ez hosszabb távon nem megoldás, valamilyen hostolt szolgáltatást kell igénybe venni a levelezésre.