Einheit 9 — VPN und seine Tücken
Was du nach dieser Einheit weißt: Du verstehst was VPN technisch tut, in welches Subnetz du damit eintrittst — und warum du aus dem VPN heraus manche Dinge nicht kannst, die ein System im internen Netzwerk kann.
Was VPN tut
VPN (Virtual Private Network) baut einen verschlüsselten Tunnel zwischen deinem Gerät und einem Netzwerk. Wenn du VPN aktivierst, bekommst du eine zweite IP-Adresse — eine aus dem Zielnetzwerk.
Ohne VPN:
Dein Laptop (185.x.x.x, öffentlich)
│
Internet
│
Kunden-Netzwerk — NICHT erreichbar von außen
Mit VPN:
Dein Laptop (185.x.x.x öffentlich + 192.168.1.200 intern)
│
VPN-Tunnel (verschlüsselt)
│
Kunden-VPN-Gateway
│
Kunden-Netzwerk — jetzt erreichbar
Dein Laptop verhält sich nach dem VPN-Verbindungsaufbau so als wäre er physisch im Büronetzwerk des Kunden.
In welchem Subnetz bist du nach dem VPN?
Das hängt davon ab wie der VPN-Server konfiguriert ist. Typischerweise bekommst du eine IP aus einem VPN-Adresspool — oft einem separaten Subnetz:
Büronetzwerk: 192.168.1.0/24
Server-Netz: 192.168.2.0/24
VPN-Pool: 192.168.10.0/24 ← deine VPN-IP kommt von hier
Das bedeutet: du bist nicht im Büronetzwerk. Du bist im VPN-Subnetz — mit seinen eigenen Firewall-Regeln.
Die Tücke: VPN ≠ internes System
Das ist der häufigste Irrtum. "Ich bin per VPN verbunden, also bin ich im internen Netzwerk."
Stimmt — aber nicht vollständig. Du bist in einem Subnetz das Zugriff auf bestimmte interne Ressourcen hat. Aber:
Die Firewall-Regeln für das VPN-Subnetz sind oft restriktiver als für interne Server.
Ein konkretes Szenario:
ERP-Datenbankserver: 192.168.2.100, Port 5432
Firewall-Regeln für Port 5432:
ERLAUBT: Von 192.168.2.0/24 (Server-Subnetz) → OK
ERLAUBT: Von 192.168.1.0/24 (Büro-Subnetz) → OK für bestimmte PCs
BLOCKIERT: Von 192.168.10.0/24 (VPN-Subnetz) → NEIN
Du bist per VPN verbunden, versuchst die Datenbank direkt anzusprechen — und kommst nicht durch. Ein interner Server im Server-Subnetz kann es problemlos.
Warum das wichtig ist:
- Du testest eine API-Verbindung manuell per VPN — es klappt (du bekommst eine andere VPN-Regel)
- Du konfigurierst 42°OS auf dem Server — es klappt nicht (42°OS hat eine andere IP, andere Regel)
- Du schließt daraus: "Die API funktioniert, also liegt der Fehler bei 42°OS" — falsch
Split Tunneling
Manche VPN-Konfigurationen nutzen Split Tunneling: nur Verkehr zu internen Adressen geht durch den Tunnel, der Rest läuft direkt über deinen normalen Internetanschluss.
Mit Split Tunneling:
192.168.x.x → durch VPN-Tunnel
8.8.8.8, google.com → direkt über deinen ISP
Ohne Split Tunneling läuft nach VPN-Verbindung der gesamte Traffic durch den Tunnel — inklusive normalem Internetzugriff.
Praxis: Warum mein Test klappt, aber 42°OS nicht
Ich sitze am Laptop, VPN aktiv:
Laptop-VPN-IP: 192.168.10.200
↓
Test: API-Aufruf an 192.168.2.50:443
↓
Firewall: VPN-Subnetz → Port 443 auf .2.50 → ERLAUBT
↓
Ergebnis: Erfolg ✅
42°OS auf Cloud-Server:
Server-IP: 185.42.11.93
↓
API-Aufruf an 192.168.2.50:443
↓
Firewall: Externe IP → Port 443 auf .2.50 → BLOCKIERT (keine Regel)
↓
Ergebnis: Timeout ❌
Diagnose: Die API funktioniert, aber von einer anderen IP. 42°OS braucht eine eigene Firewall-Freigabe für seine spezifische IP.