NAT eller din egen IPv4: hvad én videresendt port kan og ikke kan

De fleste opdager, hvad NAT betyder, cirka ti minutter efter købet. Nginx starter, curl localhost returnerer siden, og browseren på laptoppen står bare og snurrer. Intet er i stykker. Serveren har bare ingen offentlig IPv4-adresse selv, og dens eneste hoveddør er én videresendt port til SSH.

Den ene dør rækker til overraskende meget arbejde og slet ikke til nogle meget almindelige ting. Hvis du stadig vælger mellem de to slags tariffer, stiller vores ældre artikel Dedikeret IP eller NAT-VPS det ene spørgsmål, der afgør det. Denne handler om at leve med svaret: hvad en NAT-server kan i praksis, hvor den rammer en mur, og hvordan du kommer ud, når du vokser fra den.

Hvad du reelt får

En NAT-server har en privat adresse bag vores gateway. Kontrolpanelet viser en vært og en personlig port, og du forbinder sådan her:

ssh -p 20123 root@host

Porten fører til port 22 inde i din server. Alle andre indgående IPv4-porte er lukket udefra, og der er ingen mulighed for at videresende flere. Udgående er en anden sag: serveren når alt på internettet undtagen SMTP-portene 25 og 465, som er lukket på alle tariffer, NAT eller ej. De fulde regler står i Netværk og porte.

En detalje mere, som betyder noget for nogle: den udgående adresse er ikke din egen. Trafikken forlader serveren gennem en adresse, du ikke styrer, så du kan ikke sætte reverse DNS for den og ikke opbygge et afsenderomdømme på den.

Hvad der kører fint bag én port

Alt, der selv starter samtalen. Det er en større kategori, end det lyder:

• Bots, der poller. En Telegram-bot med long polling, en Discord-bot på sin gateway-forbindelse, en tradingbot, der taler med en børs' API. Alt sammen udgående.
• AI-agenter. En agent, der kalder model-API'er, browser, skriver filer og kører kode, har ikke brug for, at nogen ringer til den. Den har brug for CPU, hukommelse og en forbindelse ud.
• Workers og scrapers. Alt, der henter job fra en kø, crawler sider eller synkroniserer data efter en tidsplan.
• Byggemaskiner og runners. CI-runners registrerer sig som regel selv hos serveren og henter arbejde, så de har det fint på NAT.

Til den slags belastning er den billigste tarif ærligt talt nok. Nano koster $3 om måneden for 2 vCPU, 1 GB RAM og 15 GB disk; Small $8 for 4 vCPU, 4 GB og 35 GB. Hele listen står på en særskilt side om NAT-tariffer.

Hvor én port ikke er nok

Muren er alt, hvor en anden skal starte forbindelsen.

Et website er det oplagte eksempel. Browsere forbinder til port 443 (og 80 til omdirigeringen), og på en NAT-tarif findes de porte ikke set udefra. En ikke-standardport virker heller ikke, i hvert fald ikke på en måde, de besøgende vil acceptere.

Dit eget domæne med HTTPS rammer den samme mur to gange. Du kan pege en DNS-post på gatewayens adresse, men intet, der ankommer dér, sendes videre til din server, bortset fra din SSH-port. Og den sædvanlige måde at få et gratis certifikat på tjekker din server på port 80 eller 443.

Webhooks fejler stille. Betalingsnotifikationer, en botplatform, der sender opdateringer, en Git-server, der melder et nyt commit: de skal alle kunne nå dig. Botten, der kørte fint med long polling, holder op med at virke i det øjeblik, du skifter den til webhooks.

VPN-endepunkter, spilservere og mailservere kræver indgående porte per definition. Det samme gør alt, du gerne vil lade en kollega åbne i en browser.

Omvejene, ærligt vurderet

IPv6. Nye Linux-servere får en offentlig IPv6-adresse, og på NAT-tariffer når den serveren direkte, på enhver port. Hvis alle klienter til din tjeneste er dine egne (din laptop, dine andre servere, en overvågningsprobe med IPv6), virker det godt. Til et offentligt website gør det ikke: en del af de besøgende sidder stadig på netværk uden IPv6 og indlæser simpelthen aldrig siden. Windows-tariffer har kun IPv4 indtil videre.

En tunnel. Du kan køre en lille agent, der holder en udgående forbindelse til et relæ et andet sted, som sender offentlig trafik tilbage gennem tunnelen. Det virker, og til en demo eller et internt dashboard er det rimeligt. Til alt, der betyder noget, har du sat en tredjepart midt i hver forespørgsel, plus én ting mere, der kan gå i stykker klokken tre om natten.

En SSH-tunnel til dig selv. Hvis du er den eneste, der har brug for adminpanelet, så eksponér det slet ikke. Videresend det over den SSH-port, du allerede har:

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

Åbn derefter http://localhost:8080 på din egen maskine. Det er det mest undervurderede trick på en NAT-server, og det er alligevel mere sikkert end at lægge panelet på internettet.

Min ærlige mening: IPv6 og SSH-tunneler er gode værktøjer. En permanent offentlig tjeneste, der kører gennem en tunnel, kun fordi serveren ikke har IPv4, er som regel et tegn på, at du er vokset fra NAT.

Til din egen IPv4 uden geninstallation

Du behøver ikke bygge noget om. Åbn serveren i kontrolpanelet, vælg „Skift tarif“ og en tarif med dedikeret IP i samme størrelse eller større. Serveren genstarter én gang og kommer tilbage med sin egen offentlige IPv4-adresse, sin disk og alt, hvad du har installeret. Port 80, 443 og det, du åbner i firewallen, bliver tilgængelige, og SSH flytter til den almindelige port 22. Detaljerne står i Skift tarif.

Et par ting er værd at vide, før du klikker:

• Du betaler den forholdsmæssige forskel for resten af den aktuelle periode, fra din saldo. Nano-IP koster $8 om måneden mod $3 for Nano; Small-IP $16 mod $8.
• Det kræver en ledig adresse på serverens lokation. Er der ingen lige nu, siger kontrolpanelet det, før noget bliver trukket.
• Hvis du har rettet netværkskonfigurationen i serveren i hånden, så tjek den efter genstarten. På et standardimage anvendes den automatisk.
• Tag en backup først. Det er kun én genstart, men det er stadig dine data.

Hvor NAT ikke passer, og hvor IPv4 heller ikke gør

NAT er det forkerte valg til alt offentligt, til alt, der modtager webhooks, og til alt, der kræver en fast adresse, som nogen sætter på en allowlist. Brug ikke dage på at komme uden om det. Prisforskellen mellem Nano og Nano-IP er $5 om måneden.

Men en dedikeret IPv4 er heller ikke magi. Den får ikke et website, der blokerer datacenteradresser, til at lukke dig ind, og den redder ikke en scraper fra rate limits, for de beslutninger handler om det netværk, du befinder dig i, ikke om hvem der ellers bruger adressen. Og hvis hele dit projekt er et par bots og en agent, er en IPv4, som ingen nogensinde forbinder til, spildte penge.

Hvis du alligevel planlægger at flytte til noget større, gennemgår flyt en VPS uden nedetid rækkefølgen, og sådan læser du VPS-specifikationer hjælper, når du sammenligner tariffer.