Aby skonfigurować usługę rutingu w systemie Windows Serwer, należy zainstalować rolę
A. Hyper-V.
B. Dostęp zdalny.
C. Serwer DHCP.
D. Serwer DNS.
Poprawna odpowiedź to rola „Dostęp zdalny”, bo właśnie w tej roli w Windows Server znajduje się usługa Routing and Remote Access Service (RRAS), która odpowiada za ruting. Po zainstalowaniu roli Dostęp zdalny możesz w kreatorze roli włączyć funkcję „Routing” i skonfigurować serwer jako router IP między różnymi sieciami, np. między dwiema podsieciami LAN albo między siecią lokalną a inną siecią prywatną. W praktyce wygląda to tak, że administrator instaluje rolę Dostęp zdalny, zaznacza opcję „Routing” (czasem razem z VPN), a potem w konsoli „Routing i dostęp zdalny” definiuje interfejsy, trasy statyczne, ewentualnie protokoły routingu dynamicznego (np. RIP). Moim zdaniem to jedna z kluczowych ról, gdy Windows Server ma pełnić funkcję bramy między sieciami, a nie tylko zwykłego serwera plików czy kontrolera domeny. W środowiskach produkcyjnych zgodnie z dobrymi praktykami często wydziela się osobne serwery dla usług sieciowych, np. osobny serwer dla routingu i VPN, żeby nie mieszać tego z kontrolerem domeny. Trzeba też pamiętać o odpowiedniej konfiguracji zapory Windows oraz list ACL na interfejsach, żeby ruch był filtrowany zgodnie z polityką bezpieczeństwa firmy. Rolę Dostęp zdalny wykorzystuje się też do tuneli VPN (PPTP, L2TP, SSTP, IKEv2), a wtedy ten sam komponent RRAS realizuje zarówno ruting, jak i obsługę zdalnych połączeń. W praktyce w małych firmach Windows Server z rolą Dostęp zdalny często zastępuje dedykowany router, chociaż z mojego doświadczenia lepiej jest jednak łączyć to z profesjonalnym sprzętem sieciowym i traktować Windows jako uzupełnienie, a nie jedyne urządzenie routujące w całej infrastrukturze.
W tym zagadnieniu łatwo dać się zmylić nazwom ról, bo każda brzmi dość „sieciowo”, ale tylko jedna z nich faktycznie udostępnia funkcję routingu IP w Windows Server. Kluczowe jest zrozumienie, jak producent podzielił funkcjonalności na role i jakie są ich typowe zastosowania w infrastrukturze. Rola Hyper-V jest platformą wirtualizacji. Umożliwia tworzenie maszyn wirtualnych, przełączników wirtualnych, migawki, klastery wysokiej dostępności. Owszem, w Hyper-V można skonfigurować wirtualne przełączniki, VLAN-y czy nawet złożone topologie testowe, ale to jest warstwa wirtualizacji, a nie routingu systemu jako takiego. Hyper-V nie zamienia serwera w router IP – za to odpowiada inny komponent. Serwer DNS z kolei realizuje usługi systemu nazw domenowych. Tłumaczy nazwy (np. serwer1.firma.local) na adresy IP i odwrotnie. Jest to absolutnie kluczowy element każdej domeny Active Directory i każdej większej sieci, ale nie ma nic wspólnego z przekazywaniem pakietów między podsieciami. Częsty błąd myślowy polega na utożsamianiu „usług sieciowych” z „rutowaniem”. DNS jest usługą sieciową, ale pracuje na warstwie aplikacji, nie pełni funkcji routera. Podobnie serwer DHCP zajmuje się tylko przydzielaniem parametrów konfiguracyjnych hostom w sieci, takich jak adres IP, maska, brama domyślna, adresy DNS. DHCP wie, jakie adresy rozdać, ale sam nie przekazuje ruchu między sieciami. Często ktoś widząc opcję „brama domyślna” w DHCP zakłada, że jest to związane z routingiem po stronie serwera DHCP, a to tylko dystrybucja informacji o routerze, nie realizacja jego funkcji. W Windows Server właściwy routing IP, VPN, NAT i powiązane mechanizmy są skupione w roli „Dostęp zdalny”, w ramach usługi Routing and Remote Access Service (RRAS). To tam konfigurujemy trasy, interfejsy, NAT, a nie w DNS, DHCP czy Hyper-V. Dobre praktyki mówią, żeby precyzyjnie rozróżniać: kto nadaje adresy (DHCP), kto tłumaczy nazwy (DNS), kto wirtualizuje (Hyper-V), a kto faktycznie routuje pakiety (RRAS w roli Dostęp zdalny). Mylenie tych funkcji prowadzi później do błędnych konfiguracji i trudnych do zdiagnozowania problemów w sieci.