[Megoldva] Mini Adatparki name szerver debian 10

Fórumok

Sziasztok!

Meg kellene valósítanom egy teszt környezetet alkalmazás fejlesztéshez, amihez kellene egy http és DNS proxi szerver, amit debian 10 alatt kellene leprogramoznom.

A hálózat áll az internet felől egy Zyxel ATP200 tűzfalból, aminek a 4 LAN portján egymástól független alhálózatok vannak. Pl. 10.10.0.0/24, 10.10.1.0/24, 10.10.2.0/24, 10.10.3.0/24.

1. A 10.10.0.0/24 hálózatban van egy fizikai szerver, amin VmWare fut, azon pedig egy WIN2019 tartományvezérlő, ami DNS, DHCP, ... Win10 Kliensek, Debian 10 Cloude ... stb. , valamint virtualizálva egy Debian 10 mail (IMAPS, SMTPS) szerver, ami egy azon kívül, hogy küld, multidomain (20 domain) és fetchmaillel kérdezget le levelek külső szerverekről.

2. A 10.10.1.0/24 hálózatban van egy fizikai szerver, amin szintén VmWare van -- itt virtualizálva 2db Webmin különböző IP -ken amin futna 50 domain www (https) és mail (imaps, smtps) ftp ... stb.

3. A 10.10.2.0/24 hálózatban van egy fizikai szerver, amin szintén VmWare van -- itt virtualizálva 2db Webmin különböző IP -ken amin futna 50 domain www (https) és mail (imaps, smtps) ftp ... stb.

4. A 10.10.3.0/24 hálózatban van egy fizikai szerver, amin szintén VmWare van -- itt virtualizálva 2db Webmin különböző IP -ken amin futna 50 domain www (https) és mail (imaps, smtps) ftp ... stb.

A kb. 200 domain egy külső szolgáltatótónál van jegyezve, amik irányítva vannak az ATP200 külső címére. Sajnos csak egy db public ip van, mert az isp nem tud többet, cserében van 2/1 gbit adatkapcsolat.

Azt kellene megoldanom, hogy az internet felől az ATP200 4 LAN -ában eligazodjanak a kívülről és belülről érkező kérések, és mindez a lehetőségekhez képet gyorsan is menjen és biztonságosan.

A Hálózat gbit, a szerverek pedig, 24 CPU, 512 GB ram, 35 TB RAID6, és 8 gbit lan van mindegyikben.

Segítséget előre is köszönöm.

Hozzászólások

de mi a kerdes?

a halozatok legyen inkabb 10.10.0.0/24, 10.10.1.0/24, 10.10.2.0/24, 10.10.3.0/24.

neked aztan fura humorod van...

// getPopcorn(); 
// Feliratkozás. Kíváncsi leszek erre  a hitvitára. :)

Szerkesztve: 2021. 01. 12., k – 07:05

Tehát ha jól értem, akkor arra vagy kíváncsi, hogy hogyan kell a ATP200-at konfigurálni?

Vagy bedobálsz minden kapcsolatot egy szerverre (ami inkább kettő, de méginkább három kéne hogy legyen, de azt majd máskor), és valami adatbázis alapján ez a reverse proxy majd osztogatja szépen a forgalmat a webmines szerkezetek között?

 

Csodálom hogy még senki nem szólt bele, de azt azért hozzá kell tennem, hogy egy ilyen környezet, így, 2021-ben... hát a minimum, amint mondhatok, hogy még én se így fognék hozzá.

Kedves Fisher, nem az ATP200 -at tudom hogy kell beállítani, de sajnos ez a tűzfal nem tud 4 tartományba irányítani protkollokat, vagyis az internet felől érkező kérés esetén, ne tudja eldönteni, hogy melyik hálózatba kell irányítani, ezért kell egy mögöttes dns http proxy ami megmondja a bejövő kérésnek, hogy az adott domain melyik hálózat melyik szerverén van.

Szerkesztve: 2021. 01. 12., k – 09:01

már ezen a ponton alapvető problémák vannak...

szerintem:

- a kívánt fícsöröket a Tűzfalon kellene megvalósítani, nem valami mögöttes serveren.

- a vmware környezetnek hol lesznek a management lábai? -> kellene külön management hálózat.

 

mi az hogy webmin, amin futna x dolog???.

a webmin tudtommal egy webem management felület. azon biztosan nem fut semmi ;)

 

mi a terw a win tartománnyal? az ott majd külön életet él? vagy azzal is akar valaki kívülről kommunikálni?

Sok itt a kérdés, de főleg az hogy pontosan mit szeretnél VÉGÜL elérni.

Kedves zrubi,

többnyire az adatparkok úgy épülnek fel, hogy vannak azok a a szerverek amik domainokat futtatják valamilyen menedzsment kiszolgálón, am pl. c-panel, virtualmin, webmin, diractadmin ... stb., és vannak a nem szerverek amik ns1, ns2, ns3 ... stb., amik a kéréseket delegálják a megfelelő helyekre. A VmWare nek és amangement nek van külön leválasztott vlan hálózata a menedzsmentnek, -- amúgy ez egy jelenleg is működő hálózat. Abban az esetben ha a tűzfalon a mail és a www protokollokat a megfelelő virtualizált virtualminre irányítjuk akkor az ott futó 50 domain minden szolgáltatásával együtt működik, és fel is oldódik. Jelen esetben 4 ilyen tartomány van, és a probléma csak ott van hogy a tűzfal alacson képességei miatt kellenek a name szerverek, a megfelelő delegálás miatt.

Ennél rosszabb a helyzet. A DNS szerverek ugyanis nem delegálnak semmit, ők azt tudják megmondani, hogy egy adott domain névhez milyen IP cím tartozik. Mivel neked egy ilyen van, ezért mindenre azt fogja mondani, hogy a www.fasz-tudjamelyik-domain-melyik-vmwaren.com márpedig az 1.2.3.4. Mint minden más. Szóval ezt a DNS nem fogja neked megoldani.

Kedves kroozo a VmWare nek szerencsére ehhez semmi köze, mivel a virtualmin a domain kiszolgáló önálló dns szerverrel. Vagyis van 4 db dns kiszolgáló a 4 db címtartományban, ami a saját feloldását végzi ezáltal minden domain ami az érintett virtualmin alatt van bejegyezve, fel is oldódik, ... ez jelenleg is működik mind a 200 domain esetében, kívülről is. A probléma ott jelentkezik, hogy pl. valaki kívülről próbál egy imap fiókat beállítani, akkor nem talál a megfelelő címtartományba, mivel a tűzfalon az smtps és imaps prtokoll -t csak egy db fix ip lehet irányítani.

Ne haragudj, de próbáld meg értelmezni, amit írtam. Pontosan arról van szó, hogy teljesen mindegy, hogy feloldódik a belső dnsen a www.akarmi.hu 10.10.0.13-ra, a www.masikonvan.hu meg a 10.10.1.197-re, ez kintről senkit nem érdekel. És egyre gyanúsabb, hogy te azt hiszed, hogy ha a dnst proxyzni fogod, attól bármi megoldódik. Nem, nem fog. A DNS lekérdezések nem vesznek részt a forgalom irányításában. A kliens megkérdezi, hogy mi a www.akarmi.hu címe, és szépen arra fog csatlakozni. Mivel kintről ez mind arra az egy címre fog mutatni, ezért mindenki oda. Az, hogy egyébként ez a www.akarmi.hu-nak szólt, az max a konkrét protokollban (HTTP, TLS, stb) derül ki, már ha éppen kiderül.

Természetesen tökmindegy, hogy vmware vagy nem, azért írtam azt, mert itt most konkrétan nálad ez van.

Hát, ebben azért vannak kihívások. :)

0. A hálózatokat gondolom csak elírtad, ha nem, akkor sürgősen keress valakit a cégnél, aki beszél hálózatul.

Mivel csak DNS nevekre tudsz hagyatkozni, ezért a dolog nem triviális, kénytelen vagy belenézni a konkrét protokollokba (Illetve természetesen lehetne még portokkal játszani, de az teljesen életszerűtlennek tűnik). Gyors rátekintéssel ez a zyxel tud TLSt bontani, tehát van némi reményed, hogy legalább egy részét meg tudja oldani. Jellemzően a httpst, esetleg elég mondern kliensek esetén (van SNI) általában a tls wrappinget, belenézegetés nélkül-

De ez elég vékony remény, mert "www (https) és mail (imaps, smtps) ftp ... stb.", na ebből az imaps és smtps az sokszor StartTLS, azt nem szokták tudni, SNI sem szokott mindig lenni, az ftpnél nincs TLS, a stb meg... hét good luck :D

Általában nem nagyon van más lehetőséged, mint ezeket kitenni egy darab (nyilván HA, keepalivedvel floating IP vagy valami) reverse proxyra, kb / protokol. HTTPre jó lehet akár egy haproxy, akár egy rendesen konfigolt nginx/apache, akár valamelyik újvonalas versenyző, ilyen traefik, envoy, caddy vonalon. Bejövő Levelezéssel én nem nagyon okoskodnék proxyzással, fel kell tenni egy rendes smtp servert, és bekonfolni forwardra, ahol épp a valódi domain kiszolgáló van. Imap fejből passz.

De általában is elgondolkoznék azon, hogy legalább a levelezést tuti nem vagdalnám el, legyen egy szép központi szolgáltatás, aztán ott old meg a resource maangementet másképp, nem a "mi a hálózati forgalomban a dns alapon", meg általában is inkább ebbe az irányba indulnék, hogy kintről egy jó szolgáltatás látszon a network irányból, és azokon belül oldjátok meg az erőforrás managementet, mert ez így leginkább nettó önszopatás.

Illetve némileg magam felé hajló kézzel :) Tudok ajánlani egy jó kis zorpot is, a gpl is tud a felsoroltakból majdnem mindent reverse proxyzni neked (az imap azt hiszen nincs benne), a fizetős meg mindent, plusz kevésbé pilótavizsgás, meg megoldja a HAt is. Meg lehet hozzá embert kapni, aki meg is csinálja :)

Kedves kroozo,

HUPsz, igen, a címeket javítottam, mivel tényleg el voltak írva.

A Zyxel supporttal egyeztetve a tűzfal ugyan tud minden protokollt bontani, egyedül a titkosított levelezésben nem tejesen (bár ide is benéz, nem tudom hogy?). Ezt a fajta megoldást egy adatpark sémájára javasolták. Az adatparkok jellemzően így működnek, még a magyar hosting cégek is. A reverse proxy lenne a megoldás, ahogy írtam is és a kérdés leginkább arra irányult, hogy csinált e már valaki valami hasonlót. Mivel minden virtualmin önmagában foglalja a mail, www, dns, ftp .. stb. szolgáltatásokat, amiből jelenleg 4 db különálló szerver van, várhatóan ez a mennyiség bővülni is fog, így a tűzfalas buherálást elengedtem.  Én az alábbi rányokat nézegettem:

https://linuxize.com/post/how-to-install-and-configure-squid-proxy-on-d…https://www.tecmint.com/configure-squid-server-in-linux/https://www.howtoforge.com/how-to-deploy-a-dynamic-dns-server-with-dock…https://www.aaflalo.me/2018/10/tutorial-setup-dns-over-https-server/https://github.com/aarond10/https_dns_proxyhttps://terminaladdict.com/networking/linux/2019/09/13/DoH.html.

Azt értsd meg, hogy erre általános megoldás nincs, amit te szeretnél, hogy DNS alapon routeoljon, mert a dnsnek köze nincs a routinghoz. Minden protokollra, amit így be akarsz engedni, egyesével kell megoldást találnod, jellemzően úgy, hogy magából a forgalomból szeded ki ami kell.

- A squid a HTTPt tudja ezekből megoldani, talán még az ftpt. És egyébként se ebbe az irányba mennék, a squid alapvetően cachere való.

- A dynamic DNS szervert a hajadra kenheted, ha csak egy ipd van

- A DNS over HTTPS teljesen irreleváns szerintem, az arról szól, hogy a DNS requestek HTTPs felett mennek, nem simán az 53-on.

Summa summárum, ha ilyen szeparációt akarsz, szerezz még címet, különben szívni fogsz. Még ha össze is rakod, bárki spammer listára teszi magát, viszik az egészet magával, pl.

Szerkesztve: 2021. 01. 12., k – 11:21

Azért írtam a getPopcorn()-t, mert több féle helyes megoldás is van.

pl.: Nem lehetne a 4 host inkább egy cluster és a virtuális gépeket beszervezni alhálókba? Levelezésre meg egy dedikált vm-t?

Nem tudom mi az oka ennek a topológiának, de azt látom ezekből a vasakból többet is kilehetne hozni más szervezéssel. 

Kedves st3v3, a virtualizált Debian 10 BIND DNS és HTTPS reverse proxy némi tűzfal beállítással teljes körűen megoldotta a problémát. Már a mail forwarderek tartalom visszatöltése van folyamatban (200 domainnal kis idő még). Ugyan némi fejlesztés kell még az automatizációhoz, hogy a virtualminek automatán jegyezzék a felvett domaineket a reverse proxy ban.

Kedves Oregon, mai.domain.hu kérés nem route feledat, hanem dns feloldás, így a reverse dns delegálja a megfelelő domaint a megfelelő ip címen lévő virtualmin dns szerverének, ami feloldja a domain kérést. Értelem szerűen itt az ip címre tett mail kérés hivatkozás nem fog működni. Vagyis pl az imap vagy pop kérést minden esetben a mail.domain.hu (vagy amit akarunk pl. imap.domain.hu ... stb) hivatkozással kell indítani. Amúgy is urlb szűrés miatti athentikációnál ez szankcionálva van a postfix -ben. Itt jegyzem meg, hogy minden egyes virtualmin annyi dns szerver és értelem szerűen a virtualmin felépítése miatt amennyi doman annyi alárendelt dns szerver .. de szerencsére itt a kommunikáció automata. Vagyis a helyes sorrend 1. tűzfval -> 53 protokoll átirányítás -> 2. reverse proxy dns deb 10 -> itt beállítva a domainok és aldomainok -> feloldás ip címre a megfelelő deb 10 virtualmin -ben. Persze a köztes tűzfalak és gyorstárakat nem írtam bele, de az legyen egy másik téma -

Ott fog az egész levelezés megbukni, hogy az egy szem IP cím reverse DNS-e (mármint a való világban értett reverse DNS, tehát amikor IP címhez keresünk nevet - PTR rekord) nem lehet csak egyetlen FQDN.

Ha Te mögé teszel 200 db küldő "mail.domainem.tld" szervert ami mind a saját nevén mutatkozik be a fogadó SMTP szervernek, akkor a legtöbb kurrens SMTP rendszer el fogja utasítani a levél fogadást, mert nem egyezik az SMTP HELO név, az FQDN és a PTR rekord által mutatott név.

Magyarul: jól működő levelező szerverhez (amitől jobb eséllyel elfogadja a levelet a világ többi része) egyetlen IP címen egyetlen SMTP szervert tudsz üzemeltetni.

A Te esetedben tehát kell egy mail gateway, ami a nagyvilágra van kötve a publikus címen, és a belső sok-sok levelező szervernek/tartománynak ezt kell smarthost-nak vagy relayhost-nak (ki hogy hívja) használnia.

Ez azért nem pontosan igaz, ha jól értettem, amit írtál. A küldés ellenőrzése nem azt kívánja meg, hogy a küldő név és a küldő IP címéből visszakapott név azonos legyen, hanem azt, hogy a küldő IP címe, és az abból kapott névből kapott IP cím azonos legyen. Különben egyetlen olyan levelezőszerver sem működhetne, ami több domain nevében küld levelet.

Amúgy én sem értem a felvázolt struktúrát, és a megoldás mikéntjét.

Hát egy reverz dns, ami proxy :)

Én sem igazán értem, mit csinál. De én ehhez kicsi vagyok.

Én amire gondolok, hogy tákolt egy "proxy" dns szervert, ami a belső IP-it oldja fel és mondja meg, ahhoz melyik domain van (belül). De, hogy ennek mi értelme és az Ő szempontjából miért hasznos, nem értem. (de ugye, lehet hülyeség amit tippelek).

Az biztos, hogy mi nem vagyunk tisztában a rendszere minden titkával, nem is árult el mindent. Meg azt sem értem, hogy az egyik nap segítséget kér, a másik nap (vagy harmadik) meg konkrét megvalósítása van. 

Én amire gondolok, hogy tákolt egy "proxy" dns szervert, ami a belső IP-it oldja fel és mondja meg, ahhoz melyik domain van (belül). De, hogy ennek mi értelme és az Ő szempontjából miért hasznos, nem értem. (de ugye, lehet hülyeség amit tippelek).

Ezt a megoldást meg split-dnsnek hívják. 

Elolvastam. Szedulok.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

Szerkesztve: 2021. 01. 13., sze – 22:10

Ahogy Apám mondaná Bécsbe el lehet jutni az M1-esen is Győr felé, meg a Nyíregyháza-Kijev-Moszkva-Ulanbator-Vlagyivosztok-Tokió-Honolulu-Los Angeles-New York-Frankfurt útvonalon is..

Én nem látom értelmét, hogy külön subnet-ekbe egy-egy fizikai vasat tegyek...

Inkább készítenék egy MGMT VLAN-t a szervereknek és több más VLAN-t, amiben a VM-ek kommunikálnak.
Felesleges route-olni ilyen környezetben.

Ezen kívül egy Net felé néző HA-Proxy/Nginx/whatever átjáró kellene... Esetleg keepalived alapú virtuális IP-vel egy "cluster"...

Belülre nem tartom fontosnak DNS szervereket tenni... Mármint az információt DNS-ben tárolni.

Inkább egy Ansible/Chef/Puppet alapú konfig managementet hoznék létre.

Debian Linux rulez... :D
RIP Ian Murdock