VPN-strul

”Vet” routern hur den ska nå ditt nextcloud när du sitter inne i ditt eget nät, då, eller ansluter du i så fall direkt till servern utan att träffa routern? Det är nog problemställningen du får fundera på hur du löser.

Hos mig löser jag den situationen med split-horizon DNS: mina interna DNS-servrar är auktoritativa för min domän inom mitt nätverk och pekar ut interna adresser för namn i min domän.

En annan - mer komplex - lösning skulle kunna bygga på u-turn NAT.

Det senare kräver att din router klarar av det, medan det förra ”bara” kräver att du har fungerande DNS i ditt nätverk.

Okej, så när routern inte terminerar trafik från insidan ut via VPN-tunnelns ändpunkt så fungerar trafiken som den ska, då DNS resolve på domännamnet går till routerns externa IP-adress och hairpin NAT gör att trafiken mot publika IP-adressen från insidan översätts så att trafiken går till nginx på maskinen och Nextcloud presenteras.

Men när VPN-tunneln är uppkopplad så kommer ju all din trafik från insidan som ska gå mot en utside-adress så borde hairpinning göra att du träffar WAN IP:t och port forward tillbaks till din nginx, men i stället så blir routern förvirrad och du träffar i stället IP:t för källinterface:et till VPN-tunneln vilket är LAN IP:t som också är gateway för klienterna och du presenteras därmed med webbgränssnittet till routern i stället.

Jag har inte så stor koll på Netgear routrar och deras mjukvara, var evigheter sen jag använde sådana konsumentprodukter, men de brukar ju sällan exponera mer avancerade router-inställningar i dessa. Så frågan är om det inte är enklast för dig att sätta upp en split brain DNS-konfiguration i dnsmasq så att publika webbadressen löser upp sig till IP-adressen på maskinen där nginx körs, på vis rundar du eventuell routing-problematik med VPN-tunnel mot omvärlden.

Enklaste lösningen hade nog varit ett split dns brain-upplägg där klienten på insidan i stället serveras IP-adressen till maskinen där nginx proxy:n går när klienten är på insidan.