SQL Server a NAT

SQL Server za NAT wymaga jawnego przekierowania portu, inaczej klienci zewnętrzni nie nawiążą połączenia.

Jak NAT zmienia dostęp do SQL Server

SQL Server działający w sieci prywatnej za routerem NAT nie jest automatycznie dostępny dla klientów znajdujących się w Internecie ani w innej sieci. NAT zmienia prywatny adres serwera na adres publiczny routera, ale samo tłumaczenie adresów nie tworzy reguły, która przekazywałaby nowe połączenia do konkretnego komputera. Router odrzuci połączenie przychodzące, jeżeli nie ma skonfigurowanego przekierowania portu, a zapora sieciowa na serwerze również musi zezwalać na ruch.

W przypadku SQL Server klient musi ostatecznie dotrzeć do procesu Database Engine działającego na określonym adresie IP i porcie TCP. Przekierowanie powinno wskazywać publiczny adres routera, port wystawiony na zewnątrz oraz prywatny adres serwera z SQL Server i port nasłuchu instancji. Przykładowo router może przekazywać publiczny port TCP 51433 na prywatny adres 192.168.1.20 i port TCP 1433. Numer portu zewnętrznego nie musi być taki sam jak numer portu używany wewnątrz sieci.

Port 1433, instancje nazwane i SQL Server Browser

Domyślna instancja SQL Server standardowo korzysta z portu TCP 1433, o ile administrator nie zmienił konfiguracji. Nie oznacza to jednak, że każda instalacja SQL Server nasłuchuje na tym porcie. Instancje nazwane, takie jak SERWER\KSIĘGOWOŚĆ, często używają dynamicznie przydzielanych portów TCP. Aktualny port można sprawdzić w SQL Server Configuration Manager, w ustawieniach protokołu TCP/IP danej instancji, w sekcji IP Addresses i polu TCP Dynamic Ports albo TCP Port.

SQL Server Browser używa portu UDP 1434 do odpowiadania na zapytania o port instancji nazwanej. Przy połączeniu zapisanym jako nazwa-serwera\instancja klient może najpierw zapytać Browser, a dopiero potem połączyć się z właściwym portem TCP. NAT komplikuje ten mechanizm, ponieważ trzeba osobno przekazać UDP 1434 oraz port TCP instancji, a odpowiedź może zawierać adres prywatny nieosiągalny z zewnątrz. Z tego powodu przy dostępie przez NAT bardziej przewidywalne jest ustawienie stałego portu TCP i podanie go bezpośrednio w konfiguracji klienta.

Konfiguracja po stronie serwera i routera

Najpierw należy włączyć protokół TCP/IP dla konkretnej instancji SQL Server w SQL Server Configuration Manager, ustawić stały port oraz zrestartować usługę Database Engine, ponieważ zmiana portu nie zawsze zaczyna działać bez ponownego uruchomienia usługi. Następnie trzeba utworzyć regułę zapory systemu Windows zezwalającą na przychodzący ruch TCP wyłącznie na używany port, na przykład 1433 albo ustalony port niestandardowy. Reguła zapory nie zastępuje przekierowania w routerze, a przekierowanie w routerze nie zastępuje reguły zapory.

Po stronie NAT należy wskazać właściwy prywatny adres komputera z SQL Server. Warto użyć rezerwacji DHCP albo statycznej konfiguracji adresu, ponieważ po zmianie adresu serwera reguła przekierowania może kierować ruch do niewłaściwego urządzenia. Test powinien obejmować próbę połączenia z sieci zewnętrznej, a nie tylko z tego samego LAN-u. Z komputera klienckiego można użyć formatu tcp:publiczny-adres,51433, gdzie 51433 jest publicznym portem routera. Test poleceniem Test-NetConnection publiczny-adres -Port 51433 sprawdza osiągalność portu TCP, ale nie potwierdza jeszcze poprawnego uwierzytelnienia w SQL Server ani działania konkretnej bazy.

Adres klienta, bezpieczeństwo i rozpoznawanie awarii

Połączenie przez NAT powinno korzystać z adresu publicznego routera lub z nazwy DNS wskazującej na ten adres oraz z jawnie podanego portu. Sam zapis publiczny-adres\INSTANCJA może nie zadziałać, jeżeli SQL Server Browser nie jest dostępny przez NAT albo klient otrzyma z niego prywatny adres. Jeżeli router obsługuje hairpin NAT, ten sam publiczny adres może działać także z sieci lokalnej; bez tej funkcji test z LAN-u może dawać inny wynik niż połączenie z rzeczywistej sieci zewnętrznej.

Typowe rozróżnienie problemu jest następujące: brak odpowiedzi na port wskazuje na błędny adres, przekierowanie, zaporę albo niedziałający nasłuch TCP; osiągalny port przy błędzie logowania wskazuje na etap uwierzytelniania lub uprawnień; komunikat o nieznalezionej instancji często wiąże się z użyciem nazwy instancji bez poprawnego działania SQL Server Browser. Publiczne wystawienie portu SQL Server zwiększa powierzchnię ataku, dlatego reguła NAT i zapora powinny ograniczać źródłowe adresy IP, gdy jest to możliwe, a połączenia powinny używać szyfrowania skonfigurowanego w SQL Server i prawidłowej walidacji certyfikatu. Zmiana portu na niestandardowy nie zastępuje kontroli dostępu ani uwierzytelniania.