A tervezett hálózat a következő:
- Adott egy iroda, két hálózattal. Az external az lát nagyjából mindenfelé, az internal csak saját magán belül (az externalt sem látja). A külvilágot csak proxykon (vagy vpn-en) át érik el.
- Van egy teszt AD, két DC-vel (Version 4.8.5-Debian), sdc0 és sdc1. Mindkettőnek két-két IP címe, az internal és external hálózatokba lógatva. Ezekben az internal/external hálózatokban jobbára win10 van.
- Van egy külső hálózat, oda is kellene legalább egy, de inkább két DC (sdc2, sdc3) amik viszont elsősorban linux gépeket authentikálnának (ldap helyett), ezeknek a gépeknek csak egy-egy címük van, viszont látják mind az external, mind az internal hálózatot.
https://www.dropbox.com/s/refr69xlv20b6e6/pas.png
Egyelőre ott tartok, hogy az sdc0 - sdc1 összeállt, a samba-tool drs showrepl
nem jelez hibát, a samba-tool dns query sdc0 IRODA.EXAMPLE.COM @ ALL -U administrator
szépen listázza a tartományt, benne van az sdc0, sdc1 mindkét címével. Szóval alapvetően nem tűnik lehetetlennek.
A kinit administrator
hihető időn belül (pár másodperc) lefut, van ticket.
Az órák szinkronban vannak.
De.
A samba-tool dns query sdc0 IRODA.EXAMPLE.COM @ ALL -U administrator
bő húsz másodpercig fut.
A smbclient -L localhost -U%
a https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Director… oldallal ellentétben nem írja hogy 'Domain=[IRODA] OS=[Unix]...'
# smbclient -L localhost -U%
Sharename Type Comment
--------- ---- -------
netlogon Disk
sysvol Disk
IPC$ IPC IPC Service (Samba 4.8.5-Debian)
Reconnecting with SMB1 for workgroup listing.
Server Comment
--------- -------
Workgroup Master
--------- -------
WORKGROUP
A /etc/resolv.conf
-ba az sdc0 címeit írtam mint nameservert. A journalct, logok nem írnak semmi gyanúsat.
# Global parameters
[global]
netbios name = SDC1
realm = IRODA.EXAMPLE.COM
server role = active directory domain controller
workgroup = IRODA
[netlogon]
path = /var/lib/samba/sysvol/iroda.example.com/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
Szóval a kérdések:
- Amit tervezek az oké, vagy eleve hülyeség?
- A kliensek - w10 - mennyire lesznek betegek a szerteszét IP tartományokban lévő, esetleg elérhetetlen DC-k miatt? (Valahol rémlik, hogy el lehet magyarázni nekik, hogy mégis, melyikeket akarják használni)
- Miért ilyen lassú a dns lekérdezése? Gond ez?
Hozzászólások
Site-okat tudsz csinálni (Active Directory Sites and akármi az ADUC-ban), azokkal subnethez tudod kötni a DC-ket. Innentől kezdve a site aware kliensek (gyakorlatilag kb. a Win ill. Linux alatt az SSSD) azzal kezdenek (egyébként is azzal kezdenek, de így van értelme :) ), hogy csinálnak egy kérést a tartomány címére (iroda.example.com), fognak egy random (vagy korábbról cache-lt...) dc-t, próbálnak hozzá csatlakozni (ha nem sikerül, goto next), attól lekérik a site-ok listáját, megnézi, hogy a subnete szerint ő melyik site-hoz tartozik és onnantól kezdve az ahhoz a site-hoz tartozó DC-vel fognak előbb beszélgetni (fallbackelnek más site-ra, ha a saját site-jukhoz rendelt DC-k közül egy sem érhető el).
Én beraknám egy külön VLAN-ba a négy DC-t és a tűzfalon szűrném feléjük a forgalmat, de működhet. Arra figyelj, hogy bármelyik hálózatból bármelyik DC bármelyik címére (!) indított kapcsolat/csomag vagy sikerüljön, vagy a kliens értesüljön arról, hogy márpedig ez így nem fog menni, különben mindig TCP meg UDP timeoutokra fogsz várni.
Ha tippelnem kéne az elején az auth miatt várakozik ennyit, valahol megvár egy timeout-ot, erre utal a "hihető időn belül (pár másodperc)" is. Nem kéne annyinak lennie.
Az smbclient 4.7-ben megváltozott a kimenete, úgyhogy ez teljesen ok (https://www.samba.org/samba/history/samba-4.7.0.html)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Én beraknám egy külön VLAN-ba a négy DC-t és a tűzfalon szűrném feléjük a forgalmat
Az a gond, hogy az "internal" hálóból csak http(s) jön ki. A tűzfalat se látja. Nincs kifelé route. Se. A "remote" meg viszonylag messze van (persze ettől még lehetne ugyanabban a vlanban, de nem látom értelmét).
"Ha tippelnem kéne az elején az auth miatt várakozik ennyit, valahol megvár egy timeout-ot, erre utal a "hihető időn belül (pár másodperc)" is. Nem kéne annyinak lennie."
Igen, gyanús volt nekem, hogy ez így nem ideális. Végigzongorázom a fellelhető diagnosztikákat, hátha kiderül valami sumákság.
Az smbclient 4.7-ben megváltozott a kimenete
Áh, hurrá. Köszi.
Pedig én is afelé mennék, hogy a DC-knek 1-1 IP-je legyen 1 adott hálózatban (gyakorlatilag mindegy melyikben, különbözőekben is lehetnek) és a router-eket, tűzfalakat kell megfelelően beállítani, hogy legalább a DC-k elérjék egymást szinkronizáláshoz, illetve minden kliens elérjen min. 1 DC-t.
Nem férsz hozzá a tűzfalakhoz? Ha így van, más manageli a védelmet, akkor azt tulajdonképpen jól megfarkalod azzal, hogy a DC-ket (vagy bármilyen más gépet) belógatod mindkét hálózatba :/
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Én is afelé mennék, ha lehetne. De az internalban lévő gépek nem látnak ki a saját hálózatukból, ami némiképp problémássá teszi pl. a szinkronizálást a DC-k között.
Miért baj az, ha a DC mindkét hálózatot látja?
Miért baj az, ha bármilyen másik gép belát a két hálózatba? Ha más nem, akkor a proxy szervernek muszáj, teljesen fekete lyukban nem tudnak dolgozni az emberek.
Miért baj az, ha bármilyen másik gép belát a két hálózatba?
Azért, mert a router/tűzfal való arra, hogy megfelelően szabályozva, biztonságosan összekössön 2 (vagy több) alhálózatot és ellenőrizze, szabályozza az átmenő forgalmat. Bármi más eszköz, ami fizikailag belóg mindkét hálózatba, egy potenciális veszélyforrás, ami alkalmas lehet arra, hogy kontrollálatlanul megkerüld a tűzfalat.
A megoldás nem az, hogy belógatod mindkét hálóba, hanem hogy a megfelelő IP-k között megfelelő tűzfal-szabályokkal biztosítod az eléréseket.
Az nem megy, hogy Internal-ba és External-ba is teszel 1-1 DC-t, a 2 között pedig felhúzol egy VPN-t, amin szinkronizálni tudnak?
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Hát, ami belelóg mindkét hálózatba az a DNS, DHCP szerver és a DC-k. Én nem tartok attól, hogy vagy az lxc-t vagy a sambát meghekkelik úgy, hogy azon forgalom átmenjen(*).
Tűzfalszabályokat nem tudok tenni, mert nincs IP szintű kapcsolat a hálózatok között. Persze az megoldás lehetne, hogy a DC-ket beteszem egy harmadik (negyedik) hálózatba, és arra dobálok route-okat meg szűrögetek. Még szabad portok is akadnak a routeren. Bár az is színezi a képet, hogy a remote hálózat eleve VPN-en megy, oda is kéne DC, ami persze megoldható, de a fentiek alapján, ha magát az AD-t és/vagy a DC-ket nem zavarja hogy több lábuk van, akkor nem feltétlenül erőltetném a plusz egy hálózatot.
A VPN-t először helyből el akartam vetni, mert milyenhülyeségmár, de akár működhet is. Persze picit megdobja a bonyolultságot, és nem hiszem hogy az adott esetben megérné a plusz adminisztrációt.
*) Nem, nem állítom hogy lehetetlen, de ha már azt meg tudják oldani, akkor nem ez lesz az igazi probléma.
Nham, az alvás és egy nyugodt tíz perc sokat segített, a
samba-tool dns query
azért várt, mert a resolv.conf-ban rossz volt a domain és a search beállítás. PEBKAC.