hermes-erkenntnisse/infrastructure/2026-07-22-remote-access-vpn-pangolin-ios.md

3.3 KiB

2026-07-22 — Remote-Access-VPN: Pangolin (All-in-One) + iOS-WireGuard-Tunnel

Ziel

Niedriglatenter, verlustfreier Zugriff auf VM302 (Windows-Workstation, Kansas City) + Full-Tunnel-VPN für Laptop/iPhone/iPad. Ersetzt den zappeligen Tailscale-DERP-Weg.

Zentraler Server: tool.ki1.it (IPP-HA-VM)

  • 185.250.250.230 / IPv6 2a0a:51c1:a:415::1, Ubuntu 24.04, Docker.
  • Pangolin CE 1.21.0 (traefik v3.7 + gerbil 1.4.3 + pangolin), Dashboard https://pangolin.ki1.it, Org consoro-ug, Subnets 10.200.0.0/20 (Clients) + 10.201.0.0/20 (Utility) — bewusst NICHT im CGNAT-Bereich (sonst Tailscale-Konflikt).
  • Admin: matthias@consoro.eu / KeinPlan0815! (ymALqp!? scheiterte an Ziffern-Policy).
  • Root-API-Key server-seitig via env PANGOLIN_ROOT_API_KEY (in docker-compose), Format {id}.{secret}, Bearer. isRoot brauchte alle 165 apiKeyActions per SQL (Pangolin prüft strikt, kein Root-Bypass). Integration-API intern Port 3003 (/v1/...), extern via Traefik noch nicht geroutet.
  • tool.ki1.it ist Tailscale-Node tool-ki1 = 100.115.19.39 (--accept-routes --accept-dns=false) → routet Clients ins Tailnet.

Pangolin-Struktur

  • Site vm302 (siteId=1): Newt-Connector auf VM302 (fosrl/newt 1.15.0, C:\pangolin\newt.exe, Task PangolinNewt-vm302 SYSTEM AtStartup boot-persistent). ⚠️ Newt braucht address als <ip>/<prefix> (10.200.0.1/20) — ohne CIDR: „invalid IP address format".
  • Site local-de (siteId=2): zweiter Newt AUF tool.ki1.it selbst (/opt/newt, systemd newt-local-de.service, -native = Kernel-WG-Interface newtde), für DE-Exit.
  • Client baer-laptop (Olm, olmId jt0so6tpoayfz7n): Resource vm302-rdp (10.10.10.102:3389, Split) + de-exit-fulltunnel (0.0.0.0/0 via local-de). Full-Tunnel-Exit = tool.ki1.it (DE-IP).
  • NAT/Forwarding auf tool.ki1.it reboot-fest: sysctl ip_forward (/etc/sysctl.d/99-pangolin-de-exit.conf), iptables MASQUERADE 10.200.0.0/20 + DOCKER-USER-ACCEPT für newtde/wg-ios (Docker FORWARD-Policy=DROP sonst blockiert!), netfilter-persistent.
  • Laptop-Client: Olm-Download github.com/fosrl/olm/releases 1.8.0, Enroll olm -id jt0so6tpoayfz7n -secret <im Creds-Raum> -endpoint https://pangolin.ki1.it -org consoro-ug.

iOS: ZWEI WireGuard-Full-Tunnel (Vergleich, QR im Matrix-Creds-Raum)

Pangolin/Olm ist Desktop-only → für iPhone/iPad plain WireGuard:

  • Tunnel 1 „tool-ki1 (DE)": Server wg-ios auf tool.ki1.it, Port 51821, Subnet 10.202.0.0/24. DE-Eintritt/Exit (schnelles Surfen, DE-IP). NAT out eth0 + tailscale0 + newtde.
  • Tunnel 2 „usa1 (Ashburn/US)": Server wgi auf usa1 (178.156.172.194), Port 51821, Subnet 10.203.0.0/24. US-Eintritt/Exit. NAT out eth0 + tailscale0.
  • Beide Full-Tunnel (AllowedIPs 0.0.0.0/0), wg-quick enabled = reboot-fest. Beide erreichen Internet + Tailscale + 302.

Latenz-Messung zur 302 (RDP-Ziel 100.104.5.57, beide 0% Verlust)

Weg Latenz Jitter
Tunnel 1 (DE) → 302 ~155 ms 57 ms (zappelig)
Tunnel 2 (usa1) → 302 usa1→302 = 52 ms 6 ms (glatt)
→ Für 302-Arbeit ist Tunnel 2 (usa1/Ashburn) glatter; Tunnel 1 besser fürs Surfen. Ursache Jitter Tunnel 1: schlechtes Peering IPP→ColoCrossing/KansasCity + Tailscale-auf-Windows.

Credentials

Alle Zugangsdaten + QR-Codes + Schaubild im Matrix-Credentials-Raum !ueLiBiWPmnygFHleOo:matrix.koerners.org. Client-Private-Keys nur dort/auf den Geräten.