Każdy, kto hostuje serwer WWW w sieci lokalnej, prędzej czy później trafia na ten problem:
strona działa z Internetu, ale nie otwiera się w tej samej sieci lokalnej — mimo że używamy tej samej domeny.To nie jest błąd serwera ani przeglądarki.
To naturalne zachowanie routera, które trzeba „nauczyć” obsługiwać. Spójrzmy, co dokładnie dzieje się po drodze.
Punkt wyjścia: domena wskazuje na publiczne IP
Domena (np. moja-domena.pl) zawsze wskazuje na publiczny adres IP routera.
Nie ma znaczenia, czy użytkownik jest w LAN czy w WAN — DNS zwróci to samo IP.
I tu zaczyna się problem.
Co się dzieje, gdy łączysz się z Internetu (WAN)?
1.Przeglądarka wysyła żądanie do domeny
2.Ruch trafia na publiczne IP routera
3.Router widzi regułę dstnat
4.Przekierowuje ruch do serwera w LAN
5.Serwer odpowiada
6.Router wysyła odpowiedź do Internetu
Co się dzieje w sieci lokalnej (LAN)?
Teraz dokładnie ten sam adres, ale inna perspektywa:
- Komputer w LAN wysyła żądanie do domeny
- DNS zwraca publiczne IP routera
- Pakiet trafia do routera…
- Router przekierowuje go do serwera (
dstnat) - Serwer otrzymuje pakiet
I tutaj bez przekierowania wszystko się psuje.
Dlaczego połączenie się rozpada?
Gdy komputer w sieci lokalnej łączy się z domeną, zapytanie DNS zwraca publiczny adres IP routera. Klient wysyła więc pakiet „do Internetu”, mimo że serwer znajduje się w tej samej sieci lokalnej.
Router odbiera ten ruch i — zgodnie z regułą dstnat — przekierowuje go na prywatny adres IP serwera w LAN. Na tym etapie wszystko wygląda poprawnie.
Problem pojawia się po stronie serwera.
Serwer widzi żądanie pochodzące bezpośrednio od klienta z tej samej sieci lokalnej. Nie ma więc powodu, aby wysyłać odpowiedź przez router. Odpowiada bezpośrednio do klienta, z pominięciem routera.
Dla klienta taka odpowiedź jest niespójna. Wysłał pakiet do publicznego adresu IP, a odpowiedź przyszła z prywatnego adresu z sieci lokalnej. Stos TCP/IP uznaje to za błąd i odrzuca pakiety.
Efektem jest brak odpowiedzi w przeglądarce, długi timeout albo zerwane połączenie TCP.
Jak rozwiązuje to Hairpin NAT?
Hairpin NAT, realizowany przez regułę srcnat, zmienia sposób, w jaki serwer widzi nadawcę pakietu.
Router modyfikuje adres źródłowy ruchu wychodzącego z LAN tak, aby serwer widział router jako nadawcę połączenia. Dzięki temu odpowiedź zawsze wraca do routera, a nie bezpośrednio do klienta.
Router, znając stan połączenia, przekazuje odpowiedź dalej do właściwego urządzenia w sieci lokalnej.
Z perspektywy serwera wygląda to jak rozmowa wyłącznie z routerem.
Z perspektywy klienta — jak zwykłe połączenie z domeną w Internecie.
Rola dstnat i srcnat
Reguła dstnat odpowiada za przekierowanie ruchu — decyduje, do którego serwera ma trafić połączenie przychodzące na publiczny adres IP.
Reguła srcnat (masquerade) odpowiada za drogę powrotną — zmienia adres źródłowy pakietu i zapewnia, że odpowiedź wróci przez router.
Dopiero połączenie dstnat i srcnat sprawia, że dostęp do serwera przez domenę działa poprawnie zarówno z sieci lokalnej, jak i z Internetu.
Jak skonfigurować Hairpin NAT na MikroTiku?
Krok 1: przekierowanie portu (dstnat)
Najpierw konfigurujemy klasyczne przekierowanie portu.
Ta reguła mówi routerowi, że ruch przychodzący na publiczny adres IP ma zostać wysłany do serwera w sieci lokalnej.
Przechodzimy do IP=>Firewall=>NAT=>Add New
Dodaj komentarz