Thuis-VPN-server versus cloudserver: welke bereikt je NAS?

De tunnel komt omhoog, de client toont een groene stip, en ssh 192.168.1.20 blijft hangen tot de time-out. Precies dat overkwam mij nadat ik een kleine cloudinstantie huurde en er WireGuard op zette: handshake goed, DNS goed, en de NAS op mijn bureau even onbereikbaar alsof hij op de maan stond. Er was niets mis met de tunnel. Het endpoint stond in een netwerk zonder route naar mijn huis. De locatie van het endpoint bepaalt welke netwerken aangrenzend zijn, dus kies die op basis van de bron die je eerst moet bereiken en vergelijk hosting daarna.

Een tunnel bereikt alleen netwerken die het endpoint kan routen

Een VPN geeft je client een adres binnen het eigen routeringsdomein van het endpoint. Als de client een pakket naar 192.168.1.20 stuurt, moet het endpoint weten waar dat heen gaat. De tabel van een cloud-VM kent de VPC-subnetten van de provider; van jouw LAN heeft hij nooit gehoord. Verbonden en bereikbaar zijn twee verschillende feiten, en de meeste verwarring tussen thuis en cloud komt van het eerste als bewijs voor het tweede aanzien.

Eén commando beslist het. Op het endpoint ip route get 192.168.1.20 noemt ofwel een LAN-interface ofwel wijst naar de standaardroute. Op een thuisdoos is het antwoord de LAN-kant. Op een cloudinstantie verlaat het pakket richting internet en sterft. Aanzetten van net.ipv4.ip_forward=1 en een MASQUERADE-regel toevoegen verandert dat niet, want er is niets om naartoe te sturen tot iets aan de thuiszijde een link de cloud in beëindigt.

Het thuisgeval heeft een tweede helft: de terugweg. Pakketten die het LAN via de tunneldoos verlaten, worden NAT, of het LAN heeft een statische route terug naar het tunnelsubnet nodig. Als maar één richting werkt, controleer sysctl net.ipv4.conf.all.rp_filter. Strikte reverse-path-filtering laat antwoorden vallen die op een andere interface aankomen dan de route voorspelt, en het symptoom lijkt precies op een firewallregel.

Lees het symptoom voordat je de configuratie aanraakt

Tunnel komt niet op: sleutels, endpointadres of een geblokkeerde UDP-poort. Tunnel staat, maar LAN-hosts zijn dood: plaatsing en routing. Tunnel staat, maar browsen is dood: doorsturen, NAT of DNS. Dat zijn drie lagen en drie verschillende controles, en een toch al correcte configuratie herschrijven kost een avond.

Inkomende bereikbaarheid vanaf thuis verdient een eigen controle, want die bepaalt of hosten thuis überhaupt mogelijk is. Vergelijk het WAN-adres dat je router meldt met het adres dat een externe host ziet. Als het in 100.64.0.0/10 valt, of de twee komen niet overeen, zit je achter carrier-grade NAT en geen enkele portforwarding zal ooit werken. De echte opties zijn een relay, een cloudlink die van thuis uit naar buiten belt, of het endpoint verplaatsen.

Wat hosten thuis oplevert, en wat het kost

Thuis is de enige plaatsing die standaard in het LAN zit, en dat is de hele reden om daar een server te zetten. Apparaten die alleen op het lokale segment antwoorden, zoals printers en NAS-beheerpagina’s die niet-lokale subnetten weigeren, werken zonder extra routing. Je beheert ook zelf de machine, de router en de uplink.

De kosten zijn fysiek. Thuisupload is het plafond voor alle clients tegelijk, dus een videogesprek en een back-up concurreren om dezelfde pijp. Stroom, slijtage van de schijf, patches, een dynamisch adres dat DDNS nodig heeft, een router die UDP naar binnen moet doorsturen en mogelijk dubbel NAT komen allemaal op jou neer. Wat mensen overslaan is herstel: als de doos sterft terwijl je weg bent, sterft je enige weg naar huis mee. Houd een tweede apparaat met dezelfde sleutels, of op zijn minst een plan voor fysieke toegang.

Wil je LAN-toegang zonder de doos thuis, bouw dan een link in plaats van te doen alsof. Het cloud-endpoint wordt een router: een tunnel vanaf de thuiszijde met AllowedIPs = 192.168.1.0/24 op de cloudpeer, plus doorsturen en NAT op de clouddoos. De doorstuurhandleiding van strongSwan loopt de terughelft van die opzet door, en daar falen de meeste van deze pogingen. De thuispeer moet nu omhoog zijn wil iets werken, dus je ruilde de ene afhankelijkheid voor de andere en zou dat moeten opschrijven.

Waar een cloud-endpoint echt voor is

Een cloud-endpoint verandert je publieke uitgang. Verkeer verlaat de adresruimte van de provider, en sites zien dat adres in plaats van je thuisadres. Dat is de waarde, en daarom geeft een cloud-VPN je de NAS niet: je verplaatste de uitgang, niet het LAN.

Je draait nog steeds het gastsysteem, de VPN-dienst en de inloggegevens, terwijl de provider de hypervisor en het fysieke netwerk draait, en die splitsing telt als er om 2 uur ’s nachts iets stukgaat. Een publiek endpoint wordt continu gescand, dus houd de beheerpoort dicht, sta alleen de VPN-poort toe en patch volgens een schema. Beveiligingsgroepen en firewalls van de provider moeten die poort toestaan, en sommige clouds gooien doorgestuurd verkeer weg tenzij je de bron- en bestemmingscontrole op de instantie aanpast.

Een kleine instantie dekt een handvol clients, maar versleuteling is CPU-werk, en een burstable instantie die door haar credits heen is, gedraagt zich ongelijkmatig onder aanhoudende belasting. Kijk naar de route die je echt gebruikt, niet naar het specblad.

Een beslissing die je kunt opschrijven

De taak bepaalt de plaatsing, niet het label op de doos. Heb je een apparaat op je thuis-LAN nodig, dan is het goedkoopste juiste antwoord een endpoint thuis; een clouddoos werkt pas nadat je de link terug hebt gebouwd. Heb je een andere publieke uitgang nodig, dan is cloud het antwoord en de LAN-vraag komt nooit op. Beide willen is legitiem, maar het betekent twee endpoints, twee sleutelsets en twee gedocumenteerde routes.

Controleer vanaf de client in volgorde: handshake, peeradres, een LAN-host, dan het uitgangs-IP. curl -s https://ifconfig.me laat zien wat het internet ziet, en ip route get 192.168.1.20 laat zien wat het endpoint denkt. Als de uitgangscontrole slaagt en de NAS-controle hangt, heb je je antwoord over de plaatsing al; AllowedIPs aanpassen op de client tovert geen route tevoorschijn. Een gesplitste regel zoals 10.8.0.0/24, 192.168.1.0/24 houdt LAN-verkeer alleen in de tunnel zolang die route echt bestaat.