Będę stawiał kontroler domeny na serwerze dedykowanym. Nie jest to Azure/AWS - zwykły serwer dedykowany.
I teraz pytanie jak to ugryźć mam trzy pomysły.
1. VPN Klient - Serwer 2. VPN Site to Site 3. Otwarte porty na zewnątrz z filtrem IP dla lokalizacji gdzie jest pozostała infrastruktura (luźna myśl jest to wykonalne?)
Chyba że są jeszcze jakieś inne opcje? Przy opcji z VPN będzie to w miarę śmigać?
@itguy: To znaczy co chcesz ugryźć? Co ma kontroler domeny do VPN? Kogo z czym chcesz podłączyć i co będzie obsługiwał ten kontroler domeny. Zwykłe tunele VPN IPSec mają taką cechę (i to jeszcze puszczane przez Internet), ze to potrafi się rozłączyć. I to jest naturalne, bo Internet jest best effort.
@itguy: będziesz stawiał AD dla kogo - innych serwerów w tej sieci? Końcówek w firmie? Co chcesz osiągnąć?
Jak potrzebujesz połączyć biuro z serwerem to pkt 3 jest katastrofa no nie każdy ruch jest szyfrowany domyślnie a upewnić się ze wszystko leci pod szyfrem jest karkołomne.
S2S brzmi najrozsądniej biorąc pod uwagę nierozsadnosc stawiania AD na dedykowanym serwerze, jeśli to świeża infrastruktura.
@Loperamid Tak myślałem że opcja numer 3 jest potencjalnie niebezpieczna - ale dlaczego?
@director @Koliat - Obecnie serwer jest w siedzibie firmy - docelowo ma wylecieć i wszystko ma być na tym "zewnątrz" . (Nie pytajcie to nie moja decyzja ;) W firmie jest AD wiec chciałem najpierw utworzyć zapasowy kontroler domeny na tym dedyku. Bedę próbował połączyć serwer z firmą.
@itguy: Rozwiążesz jeden problem, a stworzysz 10 nowych. Bedziesz potrzebował redundantnego i stabilnego połączenia 2s2 VPN, które nie dość że będzie musiało mieć jakieś wsparcie ($$$) to jeszcze pewnie dobry wolument ruchu przenieść (raczej liczba pps od odszyfrowania). Obok tego serwera postawisz drugie urządzenie do VPNu i takim sposobem problem stanie się bardziej rozległy. Po drugie przy rozległych setupach VPN teraz się stosuje raczej SD-WAN.
@itguy: Przekonaj ich żeby zmienili architekturę bo to jest po prostu głupota.
1. Postaw S2S z tym swoim głównym AD na dedyku skoro chcą 2. Bieżący serwer przekształć w RO-DC - zapasowy, lokalny kontroler domeny dla biura. W wypadku awarii pracownicy będą mogli się logować, ale już nie wprowadzą żadnych zmian - "DC tylko do odczytu". 3. Jeśli szefostwo wyobraża sobie w ten sposób "pójście w chmurę" masz dwa wyjścia
@itguy: Nieszyfrowany ruch pozwoli każdemu potencjalnie po drodze modyfikować pakiety w obie strony, bez szyfrowania nie masz gwarancji że to co otrzymujesz od DCka nie zostało zmodyfikowane czy odczytane po drodze. A mogą to być hashe haseł jak Ci się LDAP zbinduje bez SSLa, mogą to być nazwy domen i komputerów wewnętrznych, mogą to być w końcu podmiany DNS na żywo. A w ostateczności, wystarczy że któryś router po drodze
@director Też uważam to za delikatnie mówiąc chory pomysł - i widzę potencjalne X problemów + dodatkowo nie mam w tym zbyt dużego doświadczenia i nie chcę zrobić żadnej lipy. Bo potem nikt nie będzie pamięta,ł że ja mówiłem że to lipa od początku - tylko że to ja to postawiłem i to moja wina że się "zesrało". Dzięki Miras.
@Koliat Dzięki za wsparcie kolego. Będę starał się przepchnąć zakup
@itguy: Off-site AD ma trochę sensu, ale nie jako jedyne źródło domeny.
SQL po VPNie będzie mulić praktycznie zawsze - do wykonania jednego widoku potrzeba często kilkunastu zapytań szeregowych (gdzie wynik pierwszego zapytania jest używany w drugim) - przy opóźnieniu LAN - 1ms - masz wtedy ~30ms czasu przekazywania informacji (15 zapytań in, 15 odpowiedzi out). Przy opóźnieniu rzędu 50ms VPN - zamiast 30 milisekund masz 1500 milisekund - różnica
@Koliat: Dzięki jeszcze raz - teraz mam trochę argumentów żeby to obalić. Widzę że masz rozległą wiedze to jeszcze podpytam. Zakładając ze kasa nie gra roli to jest jaka chmura gdzie sprawdzi się SQL + Serwer plików? Azure, AWS?
Będę stawiał kontroler domeny na serwerze dedykowanym. Nie jest to Azure/AWS - zwykły serwer dedykowany.
I teraz pytanie jak to ugryźć mam trzy pomysły.
1. VPN Klient - Serwer
2. VPN Site to Site
3. Otwarte porty na zewnątrz z filtrem IP dla lokalizacji gdzie jest pozostała infrastruktura (luźna myśl jest to wykonalne?)
Chyba że są jeszcze jakieś inne opcje? Przy opcji z VPN będzie to w miarę śmigać?
wykonalne ale mało uniwersalne i potencjalnie
Zwykłe tunele VPN IPSec mają taką cechę (i to jeszcze puszczane przez Internet), ze to potrafi się rozłączyć. I to jest naturalne, bo Internet jest best effort.
Jak potrzebujesz połączyć biuro z serwerem to pkt 3 jest katastrofa no nie każdy ruch jest szyfrowany domyślnie a upewnić się ze wszystko leci pod szyfrem jest karkołomne.
S2S brzmi najrozsądniej biorąc pod uwagę nierozsadnosc stawiania AD na dedykowanym serwerze, jeśli to świeża infrastruktura.
@director @Koliat - Obecnie serwer jest w siedzibie firmy - docelowo ma wylecieć i wszystko ma być na tym "zewnątrz" . (Nie pytajcie to nie moja decyzja ;) W firmie jest AD wiec chciałem najpierw utworzyć zapasowy kontroler domeny na tym dedyku. Bedę próbował połączyć serwer z firmą.
1. Postaw S2S z tym swoim głównym AD na dedyku skoro chcą
2. Bieżący serwer przekształć w RO-DC - zapasowy, lokalny kontroler domeny dla biura. W wypadku awarii pracownicy będą mogli się logować, ale już nie wprowadzą żadnych zmian - "DC tylko do odczytu".
3. Jeśli szefostwo wyobraża sobie w ten sposób "pójście w chmurę" masz dwa wyjścia
@Koliat Dzięki za wsparcie kolego. Będę starał się przepchnąć zakup
SQL po VPNie będzie mulić praktycznie zawsze - do wykonania jednego widoku potrzeba często kilkunastu zapytań szeregowych (gdzie wynik pierwszego zapytania jest używany w drugim) - przy opóźnieniu LAN - 1ms - masz wtedy ~30ms czasu przekazywania informacji (15 zapytań in, 15 odpowiedzi out). Przy opóźnieniu rzędu 50ms VPN - zamiast 30 milisekund masz 1500 milisekund - różnica