NAT czy własny IPv4: co może, a czego nie może jeden przekierowany port

Większość ludzi dowiaduje się, co znaczy NAT, jakieś dziesięć minut po zakupie. Nginx startuje, curl localhost zwraca stronę, a przeglądarka na laptopie tylko się kręci. Nic nie jest zepsute. Serwer po prostu nie ma własnego publicznego IPv4, a jego jedyne drzwi wejściowe to jeden przekierowany port do SSH.

Te jedne drzwi wystarczają do zaskakująco dużej ilości pracy i zupełnie nie wystarczają do kilku bardzo popularnych rzeczy. Jeśli dopiero wybierasz między dwoma rodzajami taryf, nasz starszy tekst Dedykowane IP czy VPS z NAT zadaje jedno pytanie, które to rozstrzyga. Ten artykuł jest o życiu z odpowiedzią: co serwer NAT potrafi w praktyce, gdzie uderza w ścianę i jak się wydostać, kiedy z niego wyrośniesz.

Co naprawdę dostajesz

Serwer NAT ma prywatny adres za naszą bramą. Panel pokazuje hosta i osobisty port, a łączysz się tak:

ssh -p 20123 root@host

Ten port prowadzi na port 22 wewnątrz twojego serwera. Wszystkie inne przychodzące porty IPv4 są z zewnątrz zamknięte i nie ma opcji przekierowania kolejnych. Z ruchem wychodzącym jest inaczej: serwer dosięga wszystkiego w internecie poza portami SMTP 25 i 465, które są zamknięte na każdej taryfie, z NAT czy bez. Pełne zasady są w dziale Sieć i porty.

Jeszcze jeden szczegół, ważny dla niektórych: adres wychodzący nie jest twój. Ruch wychodzi przez adres, którego nie kontrolujesz, więc nie ustawisz dla niego odwrotnego DNS ani nie zbudujesz na nim reputacji nadawcy.

Co spokojnie działa za jednym portem

Wszystko, co samo zaczyna rozmowę. A to szersza kategoria, niż się wydaje:

• Boty, które odpytują. Bot Telegram na long pollingu, bot Discord na połączeniu gateway, bot tradingowy rozmawiający z API giełdy. Wszystko wychodzące.
• Agenci AI. Agent, który woła API modeli, przegląda strony, zapisuje pliki i uruchamia kod, nie potrzebuje, żeby ktoś do niego dzwonił. Potrzebuje CPU, pamięci i wyjścia na świat.
• Workery i scrapery. Wszystko, co pobiera zadania z kolejki, przegląda strony albo synchronizuje dane według harmonogramu.
• Maszyny buildowe i runnery. Runnery CI zwykle same rejestrują się na serwerze i pobierają pracę, więc na NAT czują się dobrze.

Do takiego obciążenia najtańsza taryfa szczerze wystarcza. Nano kosztuje 3 $ miesięcznie za 2 vCPU, 1 GB RAM i 15 GB dysku; Small 8 $ za 4 vCPU, 4 GB i 35 GB. Pełna lista jest na osobnej stronie o taryfach NAT.

Gdzie jeden port nie wystarcza

Ściana to wszystko, gdzie połączenie musi zacząć ktoś inny.

Strona internetowa to oczywisty przykład. Przeglądarki łączą się z portem 443 (i 80 dla przekierowania), a w taryfie NAT tych portów z zewnątrz po prostu nie ma. Niestandardowy port też nie pomoże, przynajmniej nie w sposób, który odwiedzający zaakceptują.

Własna domena z HTTPS uderza w tę samą ścianę dwa razy. Możesz skierować rekord DNS na adres bramy, ale nic, co tam trafi, nie zostanie przekazane do twojego serwera poza portem SSH. A zwykły sposób na darmowy certyfikat sprawdza serwer na porcie 80 lub 443.

Webhooki psują się po cichu. Powiadomienia o płatnościach, platforma botów wysyłająca aktualizacje, serwer Git ogłaszający nowy commit: wszystkie muszą do ciebie dotrzeć. Bot, który świetnie działał na long pollingu, przestaje działać dokładnie w chwili, gdy przełączysz go na webhooki.

Punkty VPN, serwery gier i serwery pocztowe z definicji potrzebują portów przychodzących. Podobnie jak wszystko, co chciałbyś otworzyć koledze w przeglądarce.

Obejścia, szczerze

IPv6. Nowe serwery Linux dostają publiczny adres IPv6, a w taryfach NAT trafia on na serwer bezpośrednio, na dowolny port. Jeśli wszyscy klienci twojej usługi są twoi (laptop, inne serwery, sonda monitoringu z IPv6), działa to dobrze. Dla publicznej strony nie: część odwiedzających wciąż siedzi w sieciach bez IPv6 i po prostu nigdy nie wczyta strony. Taryfy Windows mają na razie tylko IPv4.

Tunel. Możesz uruchomić małego agenta, który trzyma wychodzące połączenie z przekaźnikiem gdzieś indziej, a ten odsyła publiczny ruch z powrotem tunelem. To działa i do dema czy wewnętrznego panelu jest rozsądne. Do czegokolwiek ważnego wstawiłeś jednak stronę trzecią w środek każdego żądania i jeszcze jedną rzecz, która może się zepsuć o trzeciej w nocy.

Tunel SSH dla siebie. Jeśli panel administracyjny jest potrzebny tylko tobie, w ogóle go nie wystawiaj. Przekieruj go przez port SSH, który już masz:

ssh -p 20123 -L 8080:localhost:8080 root@host

Potem otwórz http://localhost:8080 na swoim komputerze. To najbardziej niedoceniany trik na serwerze NAT, a przy okazji bezpieczniejszy niż wystawienie panelu do internetu.

Moje szczere zdanie: IPv6 i tunele SSH to dobre narzędzia. Stała publiczna usługa puszczona przez tunel tylko dlatego, że serwer nie ma IPv4, zwykle oznacza, że wyrosłeś z NAT.

Przejście na własny IPv4 bez reinstalacji

Nie trzeba niczego przebudowywać. Otwórz serwer w panelu, wybierz „Zmień taryfę” i taryfę z dedykowanym IP tej samej wielkości lub większą. Serwer zrestartuje się raz i wróci z własnym publicznym IPv4, swoim dyskiem i wszystkim, co zainstalowałeś. Porty 80, 443 i wszystko, co otworzysz w firewallu, staną się osiągalne, a SSH przeniesie się na zwykły port 22. Szczegóły są w dziale Zmiana taryfy.

Kilka rzeczy warto wiedzieć, zanim klikniesz:

• Dopłacasz proporcjonalną różnicę za resztę bieżącego okresu, z salda. Nano-IP kosztuje 8 $ miesięcznie wobec 3 $ za Nano; Small-IP 16 $ wobec 8 $.
• Potrzebny jest wolny adres w lokalizacji twojego serwera. Jeśli akurat go nie ma, panel powie o tym przed jakimkolwiek obciążeniem.
• Jeśli ręcznie zmieniałeś konfigurację sieci w serwerze, sprawdź ją po restarcie. Na standardowym obrazie wszystko stosuje się samo.
• Najpierw zrób kopię zapasową. To tylko jeden restart, ale dane są wciąż twoje.

Gdzie NAT się nie sprawdza, a gdzie IPv4 też nie

NAT to zły wybór dla wszystkiego, co publiczne, dla wszystkiego, co przyjmuje webhooki, i dla wszystkiego, co potrzebuje stałego adresu, który ktoś wpisze na allowlistę. Nie trać dni na obchodzenie tego. Różnica w cenie między Nano a Nano-IP to 5 $ miesięcznie.

Ale dedykowany IPv4 też nie czyni cudów. Nie sprawi, że strona blokująca adresy centrów danych cię wpuści, i nie uratuje scrapera przed limitami, bo takie decyzje zapadają na podstawie sieci, w której jesteś, a nie tego, kto jeszcze używał adresu. A jeśli cały twój projekt to kilka botów i agent, kupowanie IPv4, z którym nikt nigdy się nie połączy, to wyrzucanie pieniędzy.

Jeśli i tak planujesz przenosiny na większą konfigurację, artykuł Jak przenieść VPS bez przestoju opisuje kolejność kroków, a Jak czytać parametry VPS pomoże porównać taryfy.