Ket telephely egy windows domain

Hálózatok általános

Sziasztok,

A következő a problémám: Idáig volt egy telephely. Most az iroda fele költözik egy távoli telephelyre. Windows domainbe vannak léptetve a munkaállomások.

Meg lehet oldani, hogy csak kihúzom a gépeket az egyik irodában a falból, átviszem a másik telephelyre, kapcsolódnak a hálózatra és egyszerűen belépnek a felhasználók mintha mi se történt volna.

A Domain controllernek maradnia kell az eredeti telephelyen. Csak egy minimal környezet kialakítására van lehetőség az új helyen.

OPNSense site to site VPN-re gondoltam. Már ha ez működhet...

Van valakinek hasonló elrendezése?

Még nem álltam neki, mert kétségeim támadtak. Tudnátok valami támogatást, ötletet adni? (Most talán még minden megoldás érdekel, még nem gugliztam eleget...)

  • 1395 megtekintés

( junior013 | 2022. 04. 19., k – 10:08 )

Szerkesztve: 2022. 04. 19., k – 10:09

Ha a route-ok, tűzfalszabályok rendben vannak és a DNS mindkét telephelyen megfelelően szolgáltatja a Windows domain-hez szükséges névfeloldásokat, akkor megy simán.

De azért hosszú távon én leraknék egy DC-t a másik telephelyre is.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

( uid_3194 | 2022. 04. 19., k – 10:10 )

Mikrotik EoIP tunnel tökéletesen megoldja a problémát, évekig ment ilyen nálam 2 telephely között.

"1000/1000" - ilyen lakossági előfizetésben hol van? merthogy ami az egyik végén lefelé, az a másikon felfelé, úgyhogy azt kell nézni sávszélességben, ami a legkisebb.

"a mikrotik EoIP pedig..." - amihez kell kettő darab picityúk doboz a két végére, mert ha jól tévedek, ez egy önmagával kompatibilis megoldás...

Így van, kell a két oldalra 1-1, Mikrotik 750Gr3 20 rugó körül van darabja (bruttó), szóval 40 guriga és meg is van oldva, amúgy is kéne oda valami router, szóval talán még nem is plusz költség. Nálam évekig stabilan ment, semmi teendő nincs vele, leteszed és a két oldal olyan, mintha egy helyen lennétek, csodálatos és tiszta érzés. Ja ipsec van benne, szóval titkosított.

Én jobban félek attól, hogy a ruszkik lerohanják a Mikrotiket is, mint magától a Mikrotiktől, valamint semmiképp sem HW lock, mert szépen elfutlkorászik VM-ben is és a licenc sem ökör ára.

Viszont az említett hw meg olyan picike, hw IPSec-kel, ha elég a sebesség, akkor bestbuy, valami ipari tápról jó sokáig megvan, és el is felejted, hova tetted le, helyszűke miatt lett a PC VPN/GW is leváltva nálunk, ahhoz a nethez amúgy se kellett több.

Bár én már ACnégyzetet vennék, hasonló ár, erősebb CPU, Wifi lelőhető, ha nem kell, meg talán a ROS7-hez is jobb az ARM architektúra.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Igen, pont arra próbáltam utalni, hogy egy core komponensben egy adott termék speciális tudását csak akkor szabad kihasználni, ha nagyon-nagyon-nagyon nincs más megoldás. Az EoIP szép meg jó, de ha lehet, akkor - több okból is - célszerű elkerülni. Az egyik a termékcsapda jelensége, a másik meg az, hogy broadcast domain-t wan-on megnövelni kellően szuboptimális is lehet, pláne windows-os gépek/LAN-ra tervezett/optimalizált protokollok használata során. Egész más csomagfutási idők vannak LAN-on, mint LAN1 - internet-kapcsolat - szolgáltató1 - (peering - szolgáltató2) - internet-kapcsolat - LAN2 útvonalon.

Csak 1 hülye kérdés: EOIP-nél pl. a default gateway-t, DNS-t hogy szeded szét a 2 eltérő telephely esetében a DHCP szerveren?

Emlékeim szerint a DHCP kliensek ha kapnak 2 offert, mindig a legelsőnek kapottat fogadják el. Van akkora időkülönbség a lokális dhcp és a masik telephelyi dhcp szerver válasza között, hogy megbízhatóan mindig a közelit fogja preferalni a dhcp kliens? Feltételezve, hogy NEM akarok statikus IP-t állítgatni a klienseken, illetve MAC address-eket kézzel nyilvántartson az akinek 3 anyja van.

Ha roamingol ugyanaz az eszköz a 2 telephely között, a még valid lease-t fogja vajon használni amit a másik telephelyen kapott, és a távoli dhcp kiajánlja neki megint, benne a távoli def. gw és DNS-el? Vagy dobja a régi IP-t és preferálja az új IP-t amit a gyorsabban válaszoló helyi DHCP-től kapott? Megannyi kínzó kérdés.......

A 2. telephelyen lévő gépek is az 1. uplinkjén mennek ki a nagyvilágba? Mondjuk ezzel a sávszélességek "érdekesen" fognak alakulni, hiszen a 2. th internet felől csak annyi sávszélességet fog kapni, amennyi az 1. th uplinkjéből "jut" (1.th uplinken ott van ugye egyrészt at 1.th -> internet, 2.th. -> internet valamint az 1 th. -> 2 th. és internet -> 2. th forgalma is)...

Nem.

2 telephely, mindkettő saját internet kijárat. Amin keresztül a tunnel is felépül. Értem a kérdésed okát: a usereket lokálisan a leggyorsabb legjobb teljesítménnyel akarom internetre kapcsolni, pont kerülni akarom a centralizált (pl. 1. telephelyen keresztül) internet-kilépési pont féle megoldást.

Ezért kritikus, hogy a roamingoló kliensek mindig az adott telephely lokális internetkijáratát használják.

Ezért fáznék az ilyen kiterjesztett ethernet féle megoldastól.

Cserébe meg tudnám oldani a centralizált DLNA szervert, amit minden telephelyről lehetne hasznalni.

Nem árulok el nagy titkot, családi Média szervert akarnék így futtatni, mivel a DLNA forgalom multicast, site-to-site IPSEC VPN-en beletört a bicskám a multicast forgalom átroutolásába policy-based ipsec-nél.

Próbálom natív szoftverrel, natív lejátszóval megoldani. A Plex-hez internet is kell, nemde? Mármint az otthoni gyűjteményemet valahogy az internetet megjárva jut el, ha jól értettem a Plex filozófiáját? Plussz bármelyik pillanatban mehet az aktuális verzió a kukába, ha újabb release jön ki és az már nem támogatja az én konkrét TV-imet.

Nem feltétlenül kell internet, IP cim port kombot tudsz megadni meg a regi LG WebOS-es TV-ken (kb. 8 eves) is, ertem amit mondasz de amig a Plex szervert magadnak host-olod szerintem ettol nem kell tartani. Esetleg akkor Jellyfin, ami Open-souce is. És szeretem a nativ dolgokat, a DLNA mondjuk pont nem a barátom. A limitált feature-set hogy mindennel kompatibilis legyen meg a multicast discovery miatt ezt leginkább egy hálózatra(otthonra) találták ki. Egyébként Plex is bir DLNA server lenni.

Termékcsapda a Windows is, szerintem az nehezebben megkerülhető, mint később esetleg a Mikrotik-et leváltani valami egész másra, ha putin evtárs eltörölné a föld színéről. ;) :)

Mint írtam ez ügyben van több éves gyakorlati tapasztalatom <25 géppel tökéletesen működött évekig. Több száz gépet természetesen én sem engednék rá, de feltételeztem kevés gépről van szó, akkor meg a lehető legkevesebb munkát, gondolkodást, erőforrást ez igényli, elvégre "lusta ember spekulál". ;) :)

( zeller | 2022. 04. 19., k – 10:14 )

"A Domain controllernek maradnia kell az eredeti telephelyen. " - Mármint az egyik DC-nek, ugye? mert egy DC - nem DC. De picit távolabbról nézve... Milyen hálózati kapcsolat lesz a két telephely között (L1-ben: sávszélesség, rendelkezésre állás...)?
Hogyan és mi osztja a jelenlegi telephelyen az IP-címeket? Hol, milyen uplink/downlink sávszélesség áll rendelkezésre? Mennyi gépről/eszközről van szó? A "minimal környezet" mit jelent? minimum egy RODC-t szerintem le kéne rakni a távoli telephelyre (ha nincs két DC, akkor meg el kell gondolkodni azon, hogy legyen, és hogy hol legyen...)
 

( agostonl | 2022. 04. 19., k – 10:23 )

A minimal környezetre mehet egy Read Only DC is, akár, de DC replika nélkül ne hagyd őket!

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

( GaLbi | 2022. 04. 19., k – 11:04 )

Szia,

Simán megoldható, a következőkre érdemes oda figyelni:

- a két telephely legyen összekötve VPN- keresztül. (WireGuard javasolt, és ezt támogatja az OPNSense, tapasztalatból tudom, de lehet egy Mikrotik eszköz is RouterOSv7-tel). Ennek megfelelően hálózatott kell tervezni egy picikét. (külön szegmensek mindenhova, illetve FIX IP-s Internet kapcsolat javasolt)

-jó az irány! Kis telephelyre minimalizáljuk az eszközök darabszámát, csak router, switch, meg AP-k kellenek. Nem kell helyileg DC, hanem inkább a központban (védett helyen!) legyen beállítva több DC, amit el lehet érni. 

-a sávszélesség attól függ, hogy mi tud adni a szolgáltató, érdemes rögtön úgy gondolkodni, hogy két független vonalat beköttetni, ha az egyikkel probléma van akkor legyen backup megoldás, amire automatikusan átáll a forgalom. (olcsó internet használatánál ez alapkövetelmény!)  

-a klienseknek DNS alapján el kell érniük a DC-t. Erre több megoldás is létezik: vagy a klienseknél van beállítva, hogy a DC a DNS szerverük (DHCP-n keresztül), vagy a helyi DNS van úgy konfigurálva, hogy adott domain esetében merre találja az AD-hez tartozó DNS-t.

( jenkara | 2022. 04. 19., k – 11:09 )

Köszönöm a biztatást!

Több domain controller van/volt az irodában. Azzal nincs hiba. Az új hely viszont még annyira minimal, hogy gyakorlatilag csak egy tűzfal mögé tudom bedugni a klienseket. Az egyik telephely bérelt giga, a másik sajnos csak magán előfizetéses giga (elég lehet, nincsenek sokan.)

A DNS-eket össze fogom tudni hozni (szerintem... Bár, most hogy ).

Az izgat alapvetően, hogy ha az új irodában másik IP tartományt alakítok ki, akkor az nem rondít bele a dolgokba? Csak "azt kell tudnia a munkaállomásnak", hogy a DC-re rátaláljon? (amikor elindult az új hálózatán, akkor név<=>IP azonnal meglegyen a DC-re?)

Remélhetőleg átmeneti az állapot, tehát ha megúszható a readonly controller, akkor megpróbálnám nélküle.

Mikrotik jól hangzik, de kevés is az idő a beszerzésre. Ezért is nézegettem IPsec, vagy OpenVPN tunnelt.

"Az egyik telephely bérelt giga, a másik sajnos csak magán előfizetéses giga" - Amik a lefelé irányok maximálisan elérhető sávszélességét jelentik - neked a két oldal felfelé irányából a kisebbel kell számolnod, mint a két oldal közötti forgalomra rendelkezésre álló sávszélesség, ezt nagyon nem szabad elfelejteni.

A pici tyúk EoIP-je jó móka - ha be tudod rendesen "csomagolni", illetve konfigurálni - részemről a lakossági végpont miatt (sávszélesség és hasonlók) _is_ hanygaolnám, jóval egyszerűbb egy route-olt vpn-es móka. Szerintem...
 

- az "Active Directory Site and Services" alkalmazást segítségével lehet subneteket kialakítani, illetve meghatározni a pl. a AD replikát, meg egy-két dolgot. Javaslom megnézni.

- nem kell DC a telephelyre, nélküle is müködni fog minden

- wireguard a barátod, jobb performanciát érsz el, mint a többivel.

( jenkara | 2022. 04. 20., sze – 07:52 )

Régóta használok OpenVPN-t, alapvetően elégedett voltam vele. Bár, olvastam írásokat, ahol panaszkodtak az overheadjére.

Megvettem a WireGuard ötletet, OPNSense-el párosítva. Olvastam dicséreteket a WireGuardra, itt az ideje valami újat tanulni. Ha bejutok fizikailag az új helyre telepítem és beszámolok.

Köszönöm.

Amikor legutóbb olvastam erről a wireguard-ról, a nagy hype mögött azért volt sok elbizonytalanító gyermekbetegsége és félrevezető illetve hiányos volt a tényleges képességeinek a tételes és szavahihető leírása is. Nem véletlen hogy sok pro és kontra blogposzt született a témában:

https://tailscale.com/blog/why-not-why-not-wireguard/

Végigolvasva a szálat egy pár gondolat:

- EoIP-t nem javaslok, sem a teljesítménye alapján (óriási overhead önmagában, plusz az IPSec-é, és durván fragmentált lesz a kapcsolat, ha a tunnelen belül szeretnéd megőrizni az 1500-as MTU-t, így jeletősen kisebb szávszél lesz a tunnel-ben), sem azért, mert Layer2-es kapcsolat nem túl praktikus erre a feladatra.

- Ha Mikrotik lesz bármelyik (vagy mindkét) végen, akkor OpenVPN felejtős, mert CPU-ból megy egy szálon, a kis modellek (750Gr3, hAP ac2, stb.), és 3 Mbit/s körüli sebességet tud 90-100% CPU load mellett.

- Mikrotik sok modellje tud HW gyorsított IPSec-et, és jól, stabilan is működik. De mióta van WG a ROS7-ben, azóta eszembe nem jutna IPSec konfiggal bajlódni, ha mindkét oldal támogatja a WG-t.

- Wireguard nekem nagyon bevált site-to-site kapcsolatra, ha megérti az ember (nem bonyolult, csak kicsit más logika, mint amihez szoktunk), akkor nagyon könnyű beállítani, és Mikrotik (ROS7-tel) és OPNsense esetén is tökéletesen működik. RB750GL (jó régi modell) olyan 100 Mbit/s-t tud, 750Gr3 már 200 Mbit/s felett.

- Nem router-hez kötődően: azért álltunk át Wireguard-ra először, mert a Digi-nél valami változott (lakossági végponton), és az addig IPSec VPN 200 Mbit/s feletti sebességéből 25 Mbit/s lett, és semmi módon nem tudtunk rajta javítani, meg választ sem sikerült szerezni a miértre. Azt nem tudom, hogy ez Digi-s üzleti vonalon és/vagy más szolgáltató bármilyen vonalán előfordul-e. Ugyan azon a viszonylaton a Wireguard hozza a 200 Mbit/s feletti sebességet (ott az egyik oldali RB750Gr3 a limiter).

- Sokáig üzemeltettünk olyan hálózatot (állami cég, pénz nincs de oldd meg rendszerben), ahol a központban volt egy szem DC, azon AD integrált DHCP és DNS, a telephelyek IPSec VPN-en kapcsolódtak, mindnek saját IP tartománya volt, DHCP relay-en keresztül kapták a munkaállomások a címüket a DC-től (ha elmúlt a net, úgy sem tudtak dolgozni semmit, netezni meg szintén nem lehetett, csak a központon keresztül). Szóval működik a route-olt távoli site-ról az AD belépés gond nélkül, ha a távoli gépek is az AD DNS-ét használják (vagy van helyben azzal egyező másoltat). Persze az MS ajánlásának megfelelően a minden site-on legalább két DC a javaslot, de ha mindehol lenne egy DC, már szuper lenne szerintem.

( jenkara | 2022. 05. 09., h – 07:50 )

Sziasztok!

A jo fonok (bar nem vagyok az) nem csak iger, hanem be is tart... (Igertem, beszamolok az eredmenyrol.)

Teljes siker! :-)

Koszonom szepen a hozzaszolasokat, es kulon koszonet a WireGuard otletert! Mukodik.

Sajnos, voltak mas fennformgasok is kozben, igy legalabb egy hetet (ha nem kettot) csuszott a dolog, de mult hetvegen elkeszult a mu! A megoldas vegul is ket OPNSense WireGuard pluginnel kiegeszitve. Elso probalkozasom volt WG-al, igy kellett egy kis tanulasi fazis, de meglepoen szepen osszeallt a dolog. Nem tudom, szabad-e reklamozni a srac youtube videojat (Gateway IT), de nagyon szepen bemutatja a konfig folyamatat. Es mukodik. Ez volt a legteljesebb utmutato amit talaltam. Minden egyeb leirasbol ez-az hianyzott. A S2S VPN szepen osszeallt. Ami nalam egy kis bonyodalmat okozott, hogy az egyik oldalon harom alhalozat is van, es azoknak nem az OPNSense a default gateway-uk, tovabba a windows domainnek is mukodnie kellett, ami raadasul egy publikus domain is egyben. (Az integratornak igy volt egyszerubb a windows szervereket telepiteni... Nem igazan ertek hozza, biztosan megvolt ra a magyarazat miert is jo ez igy.)

Szoval...

  • OPNSense telepit frissit. Plugin installal.
  • SIte-ok elesztese.
  • Kliens konfigok beallitasa (figyelni, hogy minden alhalozat engedelyezett legyen a csoben amnek mukodnie kell). Ja, es inditani a WG-ot, mert telepites utan meg nem aktiv.
  • Tuzfal szabalyok allitgatasa (kulonos tekintettel ha "kisse" paranoid az ember: A megfelelo alhalozatok beengedese, DNS keresek elfogadasa, illetve a Floating reszen a WG port atengedese kulonosen fontos)
  • Nalam DNSmasq jott be mint fontos momemtum, mert ott lehetett mondani (az OPNSense feluleten), hogy amikor valaki egy bizonyos domaint keres, akkor annak ki is legyen a nevszervere.
  • Es mar csak egyetlen lepes: a windows szervereken be kellett allitani a routingot a tulso site alhalozata fele.

Ennyi volt. Ma kiderul a teljesitmeny, de a szolgaltatasok mukodnek. (Mar csak egy dolog motoszkal bennem, erre meg majd ranezek: Az idoszinkron. Alapvetoen mindenki szinkronizal, nagy gebasz nem lehet, de hat na...)

Koszonom a segitsegeteket!