SSH-verbinding via VPN mislukt – Hoe los ik dit op?

SSH werkt vaak via je normale verbinding, maar faalt wanneer een VPN is ingeschakeld. Dit bericht legt de oorzaken en praktische oplossingen uit, inclusief het behandelen van gevallen waarin servers alleen specifieke IP-adressen toestaan en VPN's wisselende adressen of verschillende protocollen gebruiken.

Het symptoom

SSH werkt ook als u geen VPN gebruikt:

ssh [email protected]

Wanneer u verbinding maakt met een VPN, treedt bij dezelfde opdracht een time-out op, loopt de verbinding vast of wordt de verbinding verbroken:

ssh: verbinding maken met host myserver.com poort 22: Verbinding is verlopen

Waarom dit gebeurt

Wanneer u verbinding maakt met een VPN, verandert uw netwerkconfiguratie: routes worden gewijzigd, DNS-servers kunnen veranderen en de VPN of de provider kan firewallregels opleggen. Veelvoorkomende oorzaken:

• VPN dwingt al het verkeer door de tunnel (volledige tunnel-VPN) — SSH wordt via de VPN gerouteerd en kan worden geblokkeerd of verkeerd worden gerouteerd.
• VPN-firewall blokkeert uitgaande SSH (poort 22) — Sommige operators of zakelijke VPN's blokkeren SSH opzettelijk om risico's te beperken.
• Wijzigingen in DNS-resolutie — de DNS-servers van de VPN verwerken uw hostnaam mogelijk niet op dezelfde manier als uw normale netwerk.
• Conflicten in de routeringstabel — verkeer naar de SSH-server gaat naar de verkeerde interface of wordt naar de tunnel geleid, maar kan niet naar de openbare server.
• Server-side IP-whitelisting — De SSH-server staat alleen bepaalde client-IP's toe. Wanneer uw IP verandert vanwege de VPN, wordt u geblokkeerd.

Snel diagnosticeren

1. Kun je de server pingen terwijl je op de VPN zit? ping mijnserver.com
2. Voer een traceroute uit om te zien waar het verkeer stopt: traceroute myserver.com (of tracert op Windows).
3. Probeer verbinding te maken via IP in plaats van hostnaam: ssh-gebruiker@.
4. Probeer een andere poort als uw server deze ondersteunt: ssh -p 2222 [email protected].
5. Controleer uw routeringstabel: IP-route (Linux/macOS) of route afdrukken (Windows).

Je kunt ook controleren of een andere VPN werkt. Bijvoorbeeld: ProtonVPN heeft een gratis abonnement die je kunt testen.

Veelvoorkomende oplossingen

1. Gebruik split tunneling

Als uw VPN-client dit ondersteunt, configureer dan split tunneling zodat het verkeer naar de SSH-server rechtstreeks via uw normale gateway gaat in plaats van via de VPN-tunnel. Voor OpenVPN kunt u een route toevoegen in de clientconfiguratie om de tunnel voor een bepaald IP-adres te omzeilen:

route 255.255.255.255 net_gateway

Hiermee krijgt het systeem de opdracht om de SSH-server te bereiken via de standaardgateway (geen VPN).

2. Gebruik een alternatieve SSH-poort

Als de VPN poort 22 blokkeert, configureer uw server dan om te luisteren op een andere poort (bijvoorbeeld 2222 of 443) en maak verbinding via ssh -p gebruiker@hostPoort 443 (HTTPS) wordt vaak toegestaan waar andere poorten geblokkeerd zijn.

3. DNS-problemen omzeilen

Probeer rechtstreeks verbinding te maken via IP of stel een vertrouwde DNS-resolver in (alleen voor probleemoplossing), zoals 8.8.8.8, om te zien of DNS de boosdoener is.

4. Voeg een statische route toe

Als het verkeer na de VPN-verbinding onjuist wordt gerouteerd, voegt u een specifieke route toe die uw SSH-bestemming via uw lokale gateway verzendt:

sudo ip route toevoegen /32 via

5. Controleer de IP-regels aan de serverzijde

Als de server IP-whitelisting gebruikt, kunnen firewalls of tools zoals fail2ban de VPN-IP's blokkeren. Controleer de logs op de server en voeg de juiste adressen toe aan de whitelist (zie het gedeelte over het roteren van IP's hieronder).

Speciaal geval: Server plaatst IP's op een witte lijst en het op een witte lijst zetten lijkt niet te werken

Wanneer een server alleen specifieke client-IP's toestaat, kan het op de whitelist plaatsen van het verkeerde adres (of één adres) ervoor zorgen dat u nog steeds wordt geblokkeerd als de VPN IP's, protocollen of meerdere egress points wijzigt. Hier zijn belangrijke nuances en aanbevelingen:

Roterende VPN-IP's en -protocollen

Veel commerciële VPN-diensten (en sommige zakelijke VPN's) bieden meerdere protocollen en meerdere uitgaande servers. Sommige providers gebruiken UDP-gebaseerde tunnels (bijv. OpenVPN over UDP) of nieuwere protocollen zoals WireGuard, die uw openbare IP-adres regelmatig kunnen wijzigen. Als uw VPN bij elke sessie een nieuw openbaar IP-adres toewijst, mislukt het op de whitelist plaatsen van één IP-adres.

Whitelist-reeksen versus enkele IP's

Om SSH te laten werken terwijl u zich op zo'n VPN bevindt, plaatsen beheerders soms een IP op de witte lijst bereik eigendom van de VPN-provider. Het op een whitelist plaatsen van bereiken vergroot de kans dat uw huidige VPN-exitnode wordt gedekt, maar het verruimt ook de toegang en verhoogt het beveiligingsrisico.

Praktische workflow

1. Identificeer de VPN-uitgaande IP('s) terwijl u verbonden bent (bezoek bijvoorbeeld een 'wat is mijn IP'-service vanuit de VPN-verbinding of controleer uw openbare IP vanaf de clientcomputer).
2. Maak een whitelist van het IP-adres of het kleinst mogelijke CIDR-bereik op de serverfirewall om uw SSH-verbinding toe te staan.
3. Voer de gewenste SSH-sessie uit.
4. Verwijder na afloop de tijdelijke, bredere whitelistvermelding om het aanvalsoppervlak te verkleinen en vergrendel opnieuw het strikte beleid. Het automatiseren van toevoegen/verwijderen met een korte wijzigingsperiode vermindert het risico.

Let op: als u beide kanten beheert, overweeg dan alternatieve veilige opties, zoals het gebruik van een jump host met gemeenschappelijke TLS, VPN-bewuste toegangsproxy's of tijdelijke, op certificaten gebaseerde SSH-authenticatie waarmee u minder afhankelijk bent van IP-whitelists.

Voorbeeld: UDP-protocollen en waarom ze belangrijk zijn

Sommige firewalls of netwerkapparaten onderscheiden verkeer op protocolniveau; UDP-gebaseerde VPN-tunnels kunnen worden afgehandeld door andere NAT-/firewallregels dan TCP. Dit kan van invloed zijn op het gebruikte uitgaande adres of op de vraag of poortdoorschakeling/NAT hetzelfde gedrag vertoont. Als u inconsistent gedrag ziet tussen protocollen, test dan de VPN met zowel UDP- als TCP-modi (indien de client dit ondersteunt) om de meest stabiele optie voor uw omgeving te vinden.

Providerspecifieke notities (gebruikerservaring)

Verschillende VPN-providers gedragen zich verschillend. Sommige gebruikers vinden bijvoorbeeld dat een provider met wisselende uitgaande IP-adressen (of veel exit-nodes) een bereikwhitelisting vereist, terwijl andere providers met stabielere exit-IP-adressen dat niet nodig hebben. Een door gebruikers gerapporteerde ervaring is dat ExpressVPN's roterende/gevarieerde exit-knooppunten vereisten whitelisting-bereiken, terwijl ProtonVPN leverde consistente resultaten op voor dezelfde workflows. Uw ervaring kan variëren; controleer altijd de uitgaande IP's en het providergedrag voordat u het firewallbeleid permanent wijzigt.

Veiligheidsoverwegingen

Het op de witte lijst plaatsen van brede IP-bereiken stelt uw server bloot aan meer potentiële aanvallers. Als u tijdelijk bepaalde IP-bereiken op de witte lijst moet plaatsen, volg dan deze best practices:

• Zet een zo klein mogelijk bereik op de witte lijst.
• Beperk de wijziging op de witte lijst in de tijd en verwijder deze direct nadat de taak is voltooid.
• Gebruik sterke authenticatie op de SSH-server (alleen openbare sleutel, geen wachtwoordauthenticatie) en overweeg waar mogelijk tweefactorauthenticatie voor SSH.
• Maak gebruik van logging, waarschuwingen en automatisering van tijdelijke toegang, zodat toevoegingen/verwijderingen aan de whitelist controleerbaar zijn.

Samenvattende checklist

Voorbeeldopdrachten

Nuttige opdrachten waarnaar in dit bericht wordt verwezen:

• Verbinden via hostnaam: ssh [email protected]
• Verbinding maken via IP: ssh-gebruiker@
• Maak verbinding via alternatieve poort: ssh -p 2222 [email protected]
• Controleer routing (Linux/macOS): IP-route
• Voeg een route toe om de VPN te omzeilen (Linux): sudo ip route toevoegen /32 via
• Voorbeeld van OpenVPN-clientroute: route 255.255.255.255 net_gateway

Laatste gedachten

SSH-problemen die alleen optreden wanneer een VPN is ingeschakeld, zijn meestal te wijten aan routing, DNS of firewall/whitelisting – en in sommige gevallen aan het gebruik van roulerende IP-adressen of verschillende transportprotocollen door de VPN-provider. Identificeer welke laag interfereert, pas de minst permissieve oplossing toe die werkt (split tunneling, minimale whitelist-bereiken of alternatieve poorten) en verwijder eventuele tijdelijke, bredere toegang wanneer u klaar bent.

Als u dat wilt, kan ik dit bericht aanpassen met stapsgewijze voorbeelden van OpenVPN/WireGuard/AnyConnect voor een specifiek besturingssysteem (Windows, macOS, Linux) of een specifieke VPN-clientconfiguratie.

Laatst bijgewerkt op 17 oktober 2025