Wat een VPS moet toestaan voordat hij je VPN kan hosten

De instantie start, pakketinstallaties slagen en de dienst meldt zelfs een actieve status, maar niets maakt verbinding. Dat patroon komt veel voor op virtuele privéservers, omdat een gast die comfortabel het internet bereikt nog steeds niet in staat kan zijn de interface te maken die je protocol wil. Vijf controles scheiden een host die een tunnel kan bedienen van een host die alleen klaar lijkt, en de eerste controle die faalt verklaart meestal alles daarna. Elk is goedkoop uit te voeren en eindigt in een beslissing in plaats van een notitie.

Bevestig de interface die het protocol nodig heeft

OpenVPN over TUN heeft het tekenapparaat en de kernelmodule erachter nodig; WireGuard heeft zijn eigen kernelondersteuning nodig of een implementatie in gebruikersruimte met bijpassende verwachtingen. Beheerde containers delen mogelijk een hostkernel die het apparaat nooit blootlegt, en sommige platforms verbieden het aanmaken van tunnelinterfaces volledig, ongeacht wat er is geïnstalleerd.

Test het vermogen in plaats van een supportpagina te lezen, want marketinglabels veranderen sneller dan de onderliggende grenzen. Een functielijst die voor één plan is geschreven, beschrijft misschien niet de kernel waarop de gast echt draait. Twee korte opdrachten beantwoorden de vraag voor de gangbare protocollen, en beide ruimen achter zich op. De opdrachten hieronder maken niets permanents aan en worden direct verwijderd.

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

Een weigering op het eerste paar betekent dat TUN niet beschikbaar is en dat de standaardmodus van OpenVPN niet kan starten; een weigering op de laatste regel betekent dat de WireGuard-kernelinterface ontbreekt. De kernel-TUN/TAP-documentatie beschrijft het apparaat dat de eerste controle test. Geen van beide fouten wordt verholpen door het VPN-pakket opnieuw te installeren.

Onthoud dat het inkomende pad twee eigenaren heeft

Netwerkregels van de provider en de firewall van de gast zijn gescheiden systemen, en verkeer moet beide overleven. Een listener die op de gast is gebonden, betekent niets als de beveiligingsgroep van de provider de poort laat vallen, en een open providerregel doet niets als de gast het pakket weigert. Controleer de listener, dan de gastregels, dan het providerpaneel, in die volgorde, en bevestig zowel het protocol als het poortnummer. Eerst naar het providerpaneel springen is hoe mensen een bereik openen dat ze niet nodig hadden.

UDP is het gebruikelijke slachtoffer: veel platforms staan TCP standaard toe en behandelen UDP-regels als een aparte vermelding. Staat de instantie achter de NAT van de provider in plaats van een openbaar adres te hebben, dan wordt port forwarden aan de providerkant een derde configuratie om af te stemmen.

Plan de terugweg, niet alleen de uitgang

Volledige tunneldienst vereist ingeschakeld doorsturen, een omzettings- of routeringsschema voor clientverkeer en een terugweg die de clientpool bereikt. Een listener openen levert niets daarvan. Een tunnel die tot stand komt maar geen nuttig verkeer draagt, faalt meestal hier en niet bij de authenticatie. Behandel een geslaagde handshake als het begin van de diagnose, niet als het einde.

Schrijf het plan als drie concrete beslissingen: welke bronbereik clients krijgen, hoe hun verkeer naar het internet gaat en hoe antwoorden de weg terug vinden. Bevestig daarna dat de kernel het met het plan eens is voordat je een client test, zodat een stille afwijking niet voor een fout aan de clientkant wordt aangezien.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

Beslis de IPv6-kwestie uitdrukkelijk

IPv6 komt via verschillende mechanismen die zich voor een gateway anders gedragen: een adres op de instantie, een gerouteerde prefix of helemaal niets. Alleen een gerouteerde prefix laat de server clients op de gebruikelijke manier adressen geven. De aanname dat een werkend IPv6-adres op de host een bruikbare clientprefix betekent, is een fout die later opduikt als half kapotte connectiviteit. Het is het soort fout dat elke test doorstaat die alleen met IPv4 wordt gedaan.

Als de provider geen prefix routeert, beslis dan of de tunnel alleen IPv4 is en of clients dat moeten weten. Een gedocumenteerde afwezigheid is veiliger dan een gedeeltelijke configuratie die IPv6-bestemmingen stil in een zwart gat stuurt voor verbonden gebruikers.

Bewijs het vanaf een externe client

Lokale dienststatus beschrijft één proces op één host. De nuttige test is een geautoriseerde client op een ander netwerk, die verbinding maakt met het profiel dat je wilt verspreiden, dan een toepassing bereikt en een naam oplost. Maak ook één keer opnieuw verbinding, want een tunnel die alleen bij de eerste poging werkt, voldoet niet aan de eis die in de praktijk het meest telt.

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

Houd de operationele basis naast de test: ruimte voor updates, begrensde logs, administratieve toegang die niet van de tunnel afhangt, een herstelconsole en een notitie over wat er met clientprofielen gebeurt wanneer de instantie opnieuw wordt gebouwd en het openbare adres verandert. Als een vereiste interface of doorstuurmodel simpelweg niet beschikbaar is, brengt geen enkele wijziging aan de clientkant het, en de eerlijke volgende stap is een ander instantietype in plaats van meer configuratie.