my personal page

Tym razem będzie opis przypadku konretnego Klienta, ale sama konfiguracja może się przydać do wielu ciekawych rzeczy.

Wyobraźmy sobie firmę z prostą instalacją Active Directory składającą się z kontrolera domeny, serwera plików, serwera SQL oraz serwera web (IIS). Wszystko to szczelnie „zamknięte” w sieci lokalnej z adresacją 192.168.1.0/24. Kontakt ze światem to dowolne łącze z jednym publicznym adresem IP i router typu „SOHO”, który potrafi zrobić NAT (co stanowi podstawową metodę dostępu do Internetu dla maszyn w sieci lokalnej) i… niewiele więcej. Za obsługę poczty, firmowej strony WWW i DNSów dla domeny odpowiadają serwery gdzieś w świecie.

W pewnym momencie na serwerze IIS został zainstalowany serwis, do którego dostęp mają mieć użytkownicy mobilni (czyli tacy, którzy mają laptopa i są czasami w siedzibie firmy, a czasami trochę dalej). I ci użytkownicy mają na swoich stacjach zainstalowany program, który łączy się ze wspomnianym serwisem. Niby nic prostszego, bo wystarczy wystawić port tcp/443 na zewnątrz za pomocą prostego przekierowania i wszystko śmiga aż miło. Ale nasi bohaterowie nie bardzo chcą zmieniać konfiguracji swojego programu za każdym razem, kiedy wychodzą z firmy, albo do niej wracają. A router jest na tyle „prosty”, że nie radzi sobie zbyt dobrze z połączeniami inicjowanymi z sieci lokalnej na zewnętrzny adres IP, który jest „zawinięty” do serwera w tejże sieci lokalnej (robi się podwójny NAT, który przerasta urządzenie sieciowe). Pojawia się więc drobny problem…

Na szczęście nasz magiczny program można skonfigurować tak, aby korzystał z nazwy domenowej, a nie adresu IP. Tylko jak w łatwy i elegancki sposób zrobić tak, żeby – w zależności od fizycznej lokalizacji laptopa – ta sama nazwa domenowa (nazwijmy ją app.firma.pl) była rozwiązywana na różne adresy IP? Zacznijmy od rzeczy prostych i oczywistych. Na pewno na serwerach DNS odpowiadających za domenę firma.pl musimy zdefiniować rekord A (albo AAAA dla IPv6) określający, że app.firma.pl znajduje się pod publicznym adresem IP przypisanym do Klienta. Drugą rzeczą jest (wspomniane już przeze mnie) przekierowanie portu tcp/443 serwera z IISem (niech będzie to 192.168.1.100) na routerze tak, aby był osiągalny z zewnątrz. Pozostaje jeszcze skonfigurować aplikacje na laptopach tak, żeby korzystał z nazwy domenowej, a nie adresu IP. Dzięki powyższym modyfikacjom wszyscy użytkownicy znajdujący się poza murami firmy powinni mieć dostęp do swoich danych. Ale co dalej?

Można na serwerach DNS domeny AD dodać strefę firma.pl, a w niej rekord „app.firma.pl. A 192.168.1.100„. Owszem, będzie działać, ale stracimy możliwość rozwiązywania innych nazw z domeny firma.pl (z wewnątrz sieci nie zadziała np. www.firma.pl), bo AD stanie się autorytatywne dla zdefiniowanej właśnie strefy. Niby można zdublować wszystkie wpisy z DNSów „publicznych”, jednak nie jest to dobry pomysł, bo trzeba będzie pilnować spójności tych dwóch systemów, co jeszcze szczególnie trudne w przypadku, gdzie zewnętrznymi zarządza ktoś inny. Poza tym jest to nieeleganckie :-)

Rozwiązanie okazuje się wyjątkowo proste. Okazuje się, że na serwerach DNS Active Directory można utworzyć nową strefę app.firma.pl, a w niej zdefiniować jeden rekord typu A z pustą nazwą (wtedy będzie się odnosił do nazwy strefy). Taka konfiguracja skutkuje kilkoma rzeczami. Po pierwsze – udało się spełnić założenie, bo adres app.firma.pl rozwiązywany jest na zewnątrz dzięki „publicznym” DNSow, a w siedzibie firmy dzięki DNSom skojarzonym z Active Directory. Po drugie – nie muszę pamiętać o synchronizacji strefy na dwóch, niezależnych systemach. A po trzecie – rozwiązanie jest proste, eleganckie i przejrzyste, więc nie trzeba tworzyć rozbudowanej dokumentacji i trenować pamięci, żeby się w tym później połapać.