> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/gateway/da/knowledge-base/knowledge-base-articles/agent-tunnel.md).

# Agenttunnel

Konfigurer Agenttunnel, så sessioner i Devolutions Gateway dirigeres via Devolutions Agent og når maskiner på private netværk uden direkte forbindelse.

{% hint style="warning" %}
**Eksperimentel** (Devolutions Gateway og Agent **2026.2.0+**). Test, før De ruller det bredt ud.
{% endhint %}

Agent Tunnel lader Devolutions Gateway nå maskiner på et privat netværk, som den ikke kan oprette direkte forbindelse til.

De installerer Devolutions Agent på en maskine inde i det netværk (en jumpvært eller en stedserver). Agenten ringer ud til gatewayen og annoncerer de IP-intervaller og domæner, den kan nå. Derefter dirigeres enhver session, De åbner via gatewayen til et af disse mål, automatisk gennem agenten. Der ændres intet for brugeren.

Denne vejledning viser, hvordan De forbinder en gateway med en agent og dirigerer trafik gennem den.

### Før De begynder

* Devolutions Gateway **2026.2.0+** og Devolutions Agent **2026.2.0+**.
* Agentmaskinen kan nå gatewayen via **HTTPS** (for at tilmelde sig) og via **UDP på port 4433** (tunnelen).
* På gatewayen/firewallen: tillad **indgående UDP 4433** fra de steder, hvor agenterne kører.
* En konto i Devolutions Server, der kan administrere gatewayen.

### Aktivér Agent Tunnel på gatewayen

Rediger `gateway.json`:

* Windows: `%ProgramData%\Devolutions\Gateway\gateway.json`
* Linux: `/etc/devolutions-gateway/gateway.json`
* macOS: `/Library/Application Support/devolutions-gateway/gateway.json`

```json
{
  "Hostname": "gateway.contoso.com",
  "AgentTunnel": {
    "Enabled": true,
    "ListenPort": 4433
  },
  "__debug__": {
    "enable_unstable": true
  }
}
```

Sæt `Hostname` til den adresse, agenterne bruger til at nå gatewayen, og genstart derefter tjenesten Devolutions Gateway.

### Generer en tilmeldingsstreng i Devolutions Server

I Devolutions Server skal De åbne ***Administration*** – ***Devolutions Gateway***, vælge Deres gateway og klikke på ***Agent Tunnel***.

Klik på knappen ***+*** for at tilføje en agent.

Angiv et ***agentnavn*** og en ***levetid***, og klik derefter på ***Generer***.

Kopiér ***tilmeldingsstrengen***.

{% hint style="warning" %}
Tilmeldingsstrengen er en engangshemmelighed. Opbevar den sikkert, og generer en ny, hvis den udløber, før De er færdige.
{% endhint %}

### Installér agenten på stedets maskine

Kør installationsprogrammet til Devolutions Agent på maskinen inde i det private netværk.

Aktivér funktionen ***Agent Tunnel***.

Indsæt tilmeldingsstrengen i ***Tilmeldingsstreng***.

Angiv de ruter, denne agent skal kunne nå:

* ***Annoncer undernet***: IP-intervaller (for eksempel `10.10.0.0/24`). Lad feltet stå tomt for automatisk at registrere lokale undernet.
* ***Annoncer domæner***: DNS-suffikser (for eksempel `*.example.com`).

Afslut guiden. Installationsprogrammet tilmelder agenten og tester forbindelsen. Hvis den ikke kan nå gatewayen, mislykkes opsætningen, så De kan rette firewallen med det samme.

### Bekræft, at agenten er online

Tilbage i dialogboksen ***Agent Tunnel*** i Devolutions Server bør agenten nu vise ***Online*** med sine undernet, domæner og tidspunkt for senest set.

{% hint style="info" %}
For at tage en agent ud af drift skal De fjerne den her og afinstallere den på maskinen.
{% endhint %}

### Opret forbindelse via gatewayen

Brugerne installerer ikke noget og opretter forbindelse via gatewayen som sædvanligt, og den dirigerer automatisk gennem agenten, når destinationen matcher.

I Remote Desktop Manager skal De åbne en session til en vært inden for et annonceret interval. Under ***VPN/tunnel/gateway*** skal De sætte typen til ***Devolutions Gateway*** og vælge den gateway, agenten blev tilmeldt med.

Sæt ***Vært*** til det interne mål (for eksempel `10.10.0.20`).

Forbind.

Sessionen åbnes via gatewayen og agenten.

### Fejlfinding

<table><thead><tr><th width="280">Problem</th><th>Kontrollér</th></tr></thead><tbody><tr><td><strong>Tilmelding mislykkes under installationen</strong></td><td>Tilmeldingsstrengen er udløbet eller indtastet forkert; gatewayen kan ikke nås via HTTPS; Agent Tunnel er ikke aktiveret på gatewayen</td></tr><tr><td><strong>Forbindelsestesten mislykkes til sidst i installationen</strong></td><td>UDP-port 4433 til gatewayen er blokeret, eller gatewayens <code>Hostname</code> er forkert</td></tr><tr><td><strong>Agenten er Online, men sessionen opretter stadig direkte forbindelse</strong></td><td>Målet ligger ikke i et annonceret undernet eller domæne; målet er kun IPv6 (brug et domæne i stedet)</td></tr><tr><td><strong>Agenten vises som Offline</strong></td><td>Genstart tjenesten Devolutions Agent på stedets maskine</td></tr></tbody></table>

Sådan tester De tunnelen fra agentmaskinen:

```bat
DevolutionsAgent.exe probe
```

### Sådan virker det

Trinnene ovenfor er alt, De skal bruge for at dirigere trafik. Dette afsnit er til læsere, der vil have detaljerne bag kulisserne.

#### Hvad er "advertisement", og hvilken topologi kræver det?

Når en agent opretter forbindelse, fortæller den gatewayen, hvilke IPv4-undernet (for eksempel `10.10.0.0/24`) og DNS-domænesuffikser (for eksempel `*.example.com`) den kan nå. Den liste er *annonceringen*. Agenten sender den igen med jævne mellemrum, så gatewayen altid har det aktuelle billede, og gatewayen holder én rutetabel pr. tilsluttet agent.

Topologi:

* Agenten opretter én udgående forbindelse til gatewayen (UDP 4433). Intet på stedet behøver en offentlig IP-adresse eller en indgående firewallregel, og derfor virker det bag NAT.
* Fordi gatewayen er mødestedet for alle forbindelser, skal den stå et sted, der kan nås af både agenterne *og* klienterne til Devolutions Server og Remote Desktop Manager. Hvis en af siderne ikke kan nå gatewayen, kan dirigering gennem en agent ikke fungere.
* Gatewayen skal have indgående UDP 4433, der kan nås fra agentstederne, plus dens normale HTTPS-lytter til tilmelding.
* Agenten skal have almindelig netværksadgang (routing og DNS) til de mål, den annoncerer. Agenten er i praksis det "sidste hop" på det private netværk.

Én gateway kan rumme mange agenter. Ét sted kan køre mere end én agent af hensyn til redundans.

#### Hvor opløses domæner og IP-adresser?

Der sker to forskellige ting:

1. **Rutematchning (på gatewayen).** Når en session starter, tager gatewayen målet fra sessionen og matcher det mod hver tilsluttet agents annoncering:
   * Et IP-mål matches mod annoncerede undernet.
   * Et værtsnavn matches mod annoncerede domæner (suffiksmatch). Gatewayen slår *ikke* DNS op her. Den sammenligner navne.
   * Det mest specifikke match vinder (et undernet-match rangerer over et domænematch, og et længere domænesuffiks rangerer over et kortere).
   * Når to online-agenter annoncerer den samme rute (et lige så specifikt match), foretrækker gatewayen den, hvis annoncering ankom senest, så den seneste vinder i praksis. Den prøves først, og gatewayen falder kun tilbage til de andre, hvis den agent ikke kan fuldføre forbindelsen. Det betyder, at der ikke er en fast "primær/backup". Den agent, der senest (gen)oprettede forbindelse eller opdaterede sine ruter, overtager.
   * Hvis intet matcher, opretter gatewayen direkte forbindelse, præcis som før Agent Tunnel fandtes.
2. **Faktisk navneopløsning (på agenten).** Gatewayen giver målet (vært og port) til den valgte agent, og agenten opløser DNS-navnet og åbner forbindelsen inde fra det private netværk. Det er hele pointen: stedets egen DNS opløser navne, som gatewayen ikke kan se. Det betyder også, at De annoncerer domæner for værter, der kun findes i intern DNS, og undernet for værter, De adresserer via IP.

Fordi undernet-matchning i dag er baseret på IPv4, kan De nå en vært, der kun har IPv6, ved i stedet at annoncere et domæne, der dækker den.

#### Hvordan holdes det sikkert?

* **Tilmelding** bruger en kortlivet tilmeldingsstreng, der genereres i Devolutions Server. Den er kun en legitimationsoplysning til opstart, ikke den langsigtede tillid.
* Agenten genererer sit eget nøglepar lokalt og sender kun en certifikatanmodning til gatewayen. Den private nøgle forlader aldrig agentmaskinen.
* Tunnelen er QUIC med gensidig TLS: gatewayen godkender agenten ud fra dens certifikat, og agenten godkender gatewayen. Derudover fastlåser agenten den nøjagtige gatewayidentitet, den så ved tilmeldingen, så en fejlagtigt udstedt eller uautoriseret certifikatmyndighed stadig ikke kan udgive sig for at være gatewayen.
* Agenten håndhæver sin egen tilladelsesliste: den nægter at åbne en forbindelse til noget uden for de undernet og domæner, den annoncerer, selv hvis den bliver bedt om det. Annonceringen er både et routingtip og en hård grænse.
* Brugergodkendelsen er uændret. Hver session kræver stadig en normal gatewaygodkendelse fra Devolutions Server, Devolutions Cloud eller PAM. Agent Tunnel ændrer kun, *hvordan* gatewayen når målet, aldrig *hvem* der må oprette forbindelse.

#### Et par ting mere, som erfarne brugere spørger om

* **Hvorfor QUIC/UDP i stedet for TCP?** Én udgående forbindelse multiplekser mange samtidige sessioner og overlever korte netværksændringer (roaming, VPN-udfald) uden at afbryde alle sessioner.
* **Kan jeg tvinge en bestemt agent?** Ja. En session kan fastlåses til én agent. Når den er fastlåst, skal den bruge den agent og fejler i stedet for stille at falde tilbage til en direkte forbindelse. En fastlåsning kan derfor ikke bruges til at omgå den tilsigtede sti.
* **Kan jeg slå Agent Tunnel fra for en enkelt session?** Ikke i dag. Der er ingen fravælgelse pr. session: gatewayen vælger stien udelukkende ud fra destinationen. Hvis et mål matcher en online-agents annoncerede ruter, går sessionen gennem den agent. For at gennemtvinge en direkte forbindelse må destinationen ikke matche nogen annonceret rute (eller agenten skal være offline eller fjernet).
* **Hvad hvis agenten går ned?** Den markeres som Offline kort efter, at den holder op med at sende opdateringer, og gatewayen stopper med at dirigere til den (med tilbagefald til direkte forbindelse eller til en anden matchende agent). Agenten genopretter selv forbindelsen med backoff, når netværket er tilbage.
* **Skal jeg forny certifikater?** Nej. Agenten fornyer sit certifikat automatisk, før det udløber, så længe tjenesten bliver ved med at køre og genoprette forbindelsen.
* **Er trafikken stadig synlig for gatewayen?** Ja. Gatewayen er stadig relæet og afslutter sessionen, så Deres eksisterende gatewaypolitikker gælder. Agent-hoppet er kun transport.
* **Hvor ligger agentens filer?** Under `%ProgramData%\Devolutions\Agent\` på Windows (certifikater i undermappen `certs`). De rører normalt aldrig ved dem, fordi installationsprogrammet og Devolutions Server administrerer dem.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.devolutions.net/gateway/da/knowledge-base/knowledge-base-articles/agent-tunnel.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.