Skal en intern tjeneste vises utenfor i en kort periode, for eksempel til en konsulent som trenger tilgang noen dager, trenger du ikke åpne en port i brannmuren. Det finnes to veier: åpne en port og sette opp port-forwarding, eller bygge en utgående tunnel. Den andre er nesten alltid bedre.
Hvorfor port-forwarding er en dårlig idé i 2026
Å åpne en port i brannmuren og sende trafikken videre til en intern tjeneste er en gammel metode. Den fungerer. Men den har én kritisk svakhet: den lager en direkte forbindelse fra internett til det interne nettverket ditt, uten noe ekstra lag med kontroll.
Når du åpner en port, blir den tilgjengelig for alle på internett, ikke bare den ene du vil slippe inn. Da må du legge til ekstra sikkerhetssjekker i applikasjonen, bruke IP-whitelisting (som kan brytes) eller sette opp ekstra proxylag. Hvert lag øker kompleksiteten, og dermed risikoen for at én feilkonfigurasjon gir full tilgang.
Hva som skjer i praksis
- Porten står åpen døgnet rundt, selv om tjenesten bare trengs én time i måneden.
- Du har ingen enkel måte å logge hvem som koblet seg på. Brannmuren logger forbindelser, ikke hvem som satt på den andre siden.
- Angrepsflaten øker. Hver åpen port er en mulig inngang for skanning, brute-force eller utnyttelse.
Port-forwarding virker, men det er unødvendig risikabelt når det finnes bedre alternativer.
Utgående tunnel: bygg broen i motsatt retning
I stedet for å la eksterne koble seg inn i nettverket ditt, lar du din egen tjeneste koble seg ut og bygge en sikker kanal tilbake. Metoden kalles gjerne «utgående tunnel» eller «reverse tunnel». Prinsippet er det samme uansett navn.
Slik fungerer det:
- En liten agent kjører internt, på en server eller container i nettverket ditt. Den starter en forbindelse ut mot en offentlig server eller tjeneste som du kontrollerer.
- Forbindelsen er persistent og kryptert, som en VPN-tunnel, men bare i én retning: ut. Ingen innkommende forbindelser trengs.
- Tilgangen kontrolleres foran. Før noen kan bruke tunnelen, må de godkjennes av en autorisasjonssjekk, for eksempel OAuth, SSO, IP-basert tilgang eller vanlig brukernavn og passord.
- Den eksterne forespørselen videresendes internt. Når noen besøker den offentlige adressen, sender systemet forespørselen gjennom den aktive tunnelen til den interne tjenesten.
Resultatet er at brannmuren står uendret, den interne tjenesten er ikke direkte eksponert, og alt som kommer inn må gjennom din egen autorisasjonslogikk først.
Når passer en utgående tunnel
Utgående tunneler passer godt når:
- Konsulenter, leverandører eller samarbeidspartnere trenger tilgang i én eller noen få dager.
- En intern tjeneste må vises utenfor, for eksempel et testmiljø, et dashbord for interne prosesser eller et verktøy som eksterne team skal bruke.
- Du trenger å vite hvem som koblet seg på, når, og hva de gjorde.
- Du ikke vil endre infrastrukturen. Tjenesten blir der den er, uten nye proxyer eller nye brannmurregler.
Det er også ofte enklere å sette opp og vedlikeholde enn port-forwarding med ekstra sikring: én agent som kjører i bakgrunnen, med minimalt vedlikehold.
Ytelse og pålitelighet
En vanlig innvending er hva som skjer hvis tunnelen faller. Det er ikke annerledes enn med en VPN eller proxy. Har du en stabil internettforbindelse, er en utgående tunnel like pålitelig som enhver annen ekstern tilkobling.
For kritiske tjenester kan du sette opp flere tunneler med lastbalansering eller failover, eller kombinere med lokal cachelagring. I de fleste tilfeller er én enkel tunnel mer enn nok, særlig sammenlignet med risikoen ved å åpne en port.
Det viktigste: tilgangsstyring foran
En utgående tunnel alene er ikke nok. Den må kombineres med tydelig autorisasjon foran den interne tjenesten. Det betyr:
- Identitetsbekreftelse med brukernavn og passord, SSO eller API-nøkler. Ingen anonym tilgang.
- Roller og rettigheter: hvem får se hva? En konsulent trenger kanskje bare lesetilgang, mens en leverandør trenger skrivetilgang til et begrenset område.
- Logging og overvåkning av alle forespørsler, så du vet nøyaktig hvem som gjorde hva, og når.
Det er her mange løsninger svikter: de skjuler tjenesten, men styrer ikke hvem som får tilgang og hvordan. En god tunnel-løsning gjør begge deler, og lar deg endre tilgang i sanntid uten å røre infrastrukturen.
Ta kontakt hvis du vil eksponere en intern tjeneste uten å åpne nye porter.
