[itguy]

#it #windowsserver #informatyka #sieci #sysadmin

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ć?

[Loperamid]

@itguy:

3. Otwarte porty na zewnątrz z filtrem IP dla lokalizacji gdzie jest pozostała infrastruktura (luźna myśl jest to wykonalne?)

wykonalne ale mało uniwersalne i potencjalnie

[d.....r]

@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.

[Koliat]

@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.

[itguy]

@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ą.

[d.....r]

@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.

[Koliat]

@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

[Koliat]

@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

[itguy]

@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

[Koliat]

@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

[itguy]

@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?

[d.....r]

@itguy: taka chmura w jakieś ty się będziesz dobrze czuł. Naturalnym wyborem jest azure. Ja takie rzeczy stawiałem na AWS.

[Koliat]

@itguy: Ja siedzę w Azure więc z tym będę doradzać, przy czym AWS ma zwykle podobne rozwiązania. Uważam też że produkty MS lepiej trzymać w chmurze MS niż w obcych cloudach. Zasada jest jednak ta sama - jak program wymaga połączenia z baz danych, to stawiasz usługi RDS jak ma działać dobrze. Użytkownicy wyrzucają sobie RemoteAppem zdalną aplikację i działają.

Dla SQL - sprawdź czy Wasz program nie wspiera przypadkiem

[itguy]

@Koliat @director @Loperamid Jeszcze raz dzięki mirasy za wyczerpujące odpowiedzi!