Proxmox a NAT – praktyka na serwerze dedykowanym

Jeśli masz własny serwer dedykowany, to bardzo szybko dochodzisz do wniosku, że jedna usługa na takim sprzęcie to lekka strata zasobów. Proxmox aż się prosi, żeby podzielić tę maszynę na kilka środowisk – testowych i produkcyjnych – w kontenerach LXC (CT) lub w maszynach wirtualnych (VM). W pewnym momencie zawsze pojawia się ten sam temat: mam jeden publiczny adres IPv4, kilka usług w środku i muszę to jakoś wystawić na świat. Tu wchodzi NAT, przekierowanie portów i – dla bardziej złożonych przypadków – hairpin NAT.

W tym artykule chcę skupić się na problemie i podejściu, a nie na konkretnej wersji Proxmoxa czy Linuxa. Pokażę, jak myśleć o NAT w Proxmox przy jednym IP i jednym prostym przykładzie z jednym CT. Jeśli interesuje Cię dokładna konfiguracja krok po kroku, na moim kanale YouTube pokazuję to rozwiązanie praktycznie – z terminalem i interfejsem Proxmoxa na żywo.

Dlaczego Proxmox i środowisko multi‑CT/VM na serwerze dedykowanym?

Serwery dedykowane potaniały na tyle, że bardzo często opłaca się wziąć jednego „mocniejszego” i logicznie go podzielić, zamiast kupować kilka mniejszych VPS‑ów. Proxmox od lat jest u mnie numerem jeden do takiego podziału:

• prosty w instalacji,
• darmowy,
• świetnie wspiera zarówno LXC (CT), jak i pełne VM,
• da się go sensownie zautomatyzować.

Naturalnym krokiem jest więc zrobienie małej „chmury” na jednym serwerze: osobne CT na DNS, WWW, pocztę, filtr (np. Proxmox Mail Gateway), być może jeszcze jakiś monitoring czy środowisko testowe.

Z mojego doświadczenia CT sprawdzają się tu świetnie – są lekkie, szybko się uruchamiają i łatwo się je backupuje. VM dają z kolei większą izolację. Różnicom CT vs VM planuję poświęcić osobny materiał, bo to temat na cały odcinek, a nie jeden akapit.

Co właściwie robi NAT w Proxmox?

Zakładam typową sytuację: masz jeden publiczny IPv4 przypisany do serwera dedykowanego. W środku chcesz mieć prywatną sieć (np. 19.128.23.0/24), gdzie żyją Twoje CT i VM. To właśnie NAT spina te dwa światy.

Z perspektywy Proxmoxa i iptables mamy trzy podstawowe „klocki”: 

• SNAT (Source NAT / MASQUERADE) – pozwala kontenerom i VM wychodzić na świat przez publiczny IP serwera. Z punktu widzenia Internetu wszystko wygląda tak, jakby ruch szedł tylko z adresu hosta.
• DNAT (Destination NAT / port forwarding) – pozwala ruch z Internetu kierować do konkretnych CT/VM, np. port 80 na serwer WWW w kontenerze, port 25 na CT z Postfiksem.
• Hairpin NAT – specjalny przypadek, gdy maszyna wewnętrzna próbuje połączyć się z usługą za NAT-em, używając publicznego adresu serwera. Bez hairpin NAT zwykle kończy się to timeoutem albo niewidoczną usługą.

W praktyce, jeśli masz jeden IP i kilka usług w środku, bez NAT‑u się po prostu nie da.

Minimalny przykład: jeden CT za NAT‑em

Dla uproszczenia weźmy scenariusz z jednym kontenerem: 

• serwer dedykowany z jednym publicznym IPv4,
• w Proxmoxie tworzysz prywatną sieć vmbr1, np. 192.168.23.0/24,
• masz CT z WWW pod adresem 192.168.23.20,
• chcesz:
  • pozwolić temu CT wychodzić do Internetu (aktualizacje, pakiety),
  • wystawić HTTP/HTTPS na świat z tego CT,
  • uniknąć w przyszłości dziwnych problemów, gdy inny CT próbuje wejść na ten sam serwer po domenie.

W dużym skrócie:

1. Host Proxmox ma publiczny IPv4 na interfejsie zewnętrznym (np. eth0 albo vmbr0).
2. CT z WWW siedzi w prywatnej sieci (np. 192.168.23.20 na bridge’u wewnętrznym).
3. Na hoście włączasz routowanie IP i dodajesz reguły NAT:
   • SNAT/MASQUERADE – wyjście na świat,
   • DNAT – kierowanie ruchu z portu 80/443 na 192.168.23.20.

W artykule nie rozpisuję dokładnie wszystkich komend, bo to bardzo mocno zależy od wersji systemu, konkretnej konfiguracji sieci i w momencie, gdy czytasz ten tekst, może się już zdezaktualizować. W filmie na kanale pokazuję natomiast tę samą logikę na żywym systemie – tam możesz zobaczyć dokładne reguły i sposób ich podpięcia pod konfigurację sieci.

SNAT – wypuszczenie CT do Internetu

Druga część układanki to wyrzucenie ruchu z prywatnej sieci na zewnątrz. Bez tego kontenery co najwyżej będą się widzieć między sobą.

Za to odpowiada MASQUERADE w łańcuchu POSTROUTING:

Dzięki temu: 

• z punktu widzenia Internetu ruch wygląda, jakby szedł z publicznego IP hosta czyli serwera dedykowanego,
• odpowiedzi z powrotem są kierowane do właściwych CT dzięki tablicom śledzenia połączeń (conntrack).

W filmie pokazuję, jak sprawdzić, że ruch rzeczywiście przechodzi – prostym ping.

DNAT – wystawienie kontenera na świat

Logika DNAT jest prosta: ruch przychodzący na publiczny adres i konkretny port ma trafić do wybranego CT/VM w sieci prywatnej.

Przykładowo:

• ruch HTTP z Internetu na port 80 publicznego IP serwera,
• ma zostać przekierowany do CT z WWW: 192.168.23.20:80.

Technicznie realizujesz to regułą w stylu:

To tylko koncepcja – u Ciebie interfejs i adresy będą inne, ale zasada pozostaje ta sama niezależnie od wersji Proxmoxa czy dystrybucji.

Hairpin NAT – kiedy kontener nie potrafi „połączyć się sam ze sobą”

Tu dochodzimy do problemu, który prędzej czy później się pojawia:

• kontener próbuje połączyć się z usługą wystawioną na tym samym serwerze, ale przez publiczny adres IP.

Przykłady z życia: 

• CT z aplikacją WWW testuje swój własny URL, który w DNS wskazuje na publiczne IP serwera,
• klient poczty w kontenerze łączy się z serwerem MX, który jest tym samym serwerem fizycznym.

Na typowo ustawionym NAT efekt jest taki:

• z zewnątrz działa idealnie,
• z CT – timeout, brak odpowiedzi albo bardzo dziwne zachowanie.

Problem nazywa się hairpin NAT. Ruch:

• wychodzi z CT do publicznego IP serwera,
• wraca na ten sam serwer,
• i jeśli nie ma odpowiedniej reguły, po prostu nie jest prawidłowo „zawrócony” do właściwego CT.

Rozwiązaniem jest dodatkowa reguła NAT w POSTROUTING, która pozwala ruchowi z prywatnej sieci traktować inny host z tej samej sieci tak, jakby był „na zewnątrz”:

W praktyce często ta reguła jest nieco bardziej zawężona (do konkretnego hosta lub interfejsu), ale idea jest ta sama:

kontener może używać publicznego adresu serwera tak samo jak „świat zewnętrzny”.

Typowe problemy z NAT w Proxmox (z mojego doświadczenia)

Przy takim podejściu do NAT w Proxmox najczęściej pojawiają się trzy kategorie problemów.

1. Po pierwsze – reguły znikają po restarcie.
   Dodanie iptables „z palca” działa do pierwszego rebootu. Potem wszystko wraca do domyślnego stanu i usługi magicznie „przestają działać”. Rozwiązaniem jest:
   • wpięcie reguł w konfigurację sieci (np. post-up/post-down),
   • albo użycie osobnego mechanizmu do trwałego zapisywania reguł.
2. Po drugie – konflikty portów i usług na hoście.
   Jeżeli host Proxmox też słucha na jakimś porcie (np. 80/443 dla panelu), to przekierowanie tego portu na CT może skończyć się zabawnymi efektami. Trzeba świadomie zdecydować:
   • które porty są „dla hosta”,
   • które porty są „dla NAT‑owanych usług”.
3. Po trzecie – subnety i nakładanie się adresacji.
   Jeśli Twoja prywatna sieć w Proxmoxie nachodzi się z innymi sieciami (np. z siecią biurową, z której się łączysz), debugowanie routingu i NAT‑u robi się znacznie mniej przyjemne. Warto od razu dobrać takie zakresy, które nie będą się gryzły z innymi.

Do diagnozowania tego typu problemów bardzo polecam:

• tcpdump – żeby zobaczyć, czy pakiety w ogóle dochodzą tam, gdzie trzeba,
• conntrack – żeby podejrzeć, jak kernel śledzi połączenia i gdzie giną.

Zalety i ograniczenia takiej architektury

Dla porządku – kilka plusów i minusów podejścia „jeden dedyk + Proxmox + NAT + CT/VM”.

Plusy: 

• maksymalne wykorzystanie serwera – wiele usług na jednym fizycznym sprzęcie,
• pełna kontrola nad ruchem – wystawiasz tylko to, co chcesz, na portach, które Ci odpowiadają,
• separacja usług – każdy CT/VM może mieć własne pakiety, konfigurację, backupy,
• przy poprawnie ustawionym NAT i hairpin NAT wszystko działa spójnie zarówno z zewnątrz, jak i z wnętrza.

Minusy:

• rosnąca złożoność reguł NAT w miarę dokładania kolejnych usług,
• hairpin NAT i routing to tematy, które „lubią” karać za drobne błędy,
• debugowanie sieci wymaga już pewnego obycia (to nie jest poziom „klikam dalej, dalej, zakończ”).

Jeśli chodzi o CT vs VM:

• CT idealnie nadają się do serwerów usługowych (DNS, WWW, PMG) – są lekkie i szybkie,
• VM są lepsze tam, gdzie potrzebujesz twardej izolacji i osobnego kernela.

Jak wspominałem wcześniej – temu porównaniu poświęcę osobny materiał, bo w praktyce decyzja „CT czy VM” bardzo zależy od konkretnego use case’u.

Co dalej: praktyczny film i kolejne materiały

Ten artykuł celowo trzyma się poziomu koncepcji, a nie konkretnej wersji Proxmoxa czy dystrybucji.

Chodziło mi o to, żeby pokazać jak myśleć o NAT w Proxmox na jednym IP, a nie dać listę komend, która za dwie wersje systemu będzie wymagała korekty. 

Jeśli chcesz zobaczyć:

• jak wygląda przykładowa konfiguracja sieci w Proxmox,
• jak dodaję reguły NAT, DNAT i hairpin NAT,
• jak to wszystko przetestować w praktyce,

to zapraszam na mój kanał YouTube, gdzie pokazuję dokładnie ten scenariusz na żywym środowisku, krok po kroku.

W planie mam też kolejne materiały:

• porównanie CT vs VM pod usługi typu DNS/WWW/Postfix/PMG,
• dobre praktyki backupów i automatyki w Proxmox,
• osobny odcinek o IPv6 w tego typu architekturze.

Jeśli ten temat Cię interesuje, warto śledzić kolejne publikacje – zarówno na stronie, jak i na kanale.