Vad en VPS måste tillåta innan den kan vara värd för din VPN

Instansen startar, paketinstallationer lyckas och tjänsten rapporterar till och med ett körande tillstånd, men ingenting ansluter. Mönstret är vanligt på virtuella privata servrar, eftersom en gäst som enkelt når internet fortfarande kan sakna förmåga att skapa det gränssnitt ditt protokoll vill ha. Fem kontroller skiljer en värd som kan betjäna en tunnel från en som bara ser redo ut, och den första kontroll som misslyckas förklarar vanligtvis allt därefter. Var och en är billig att köra och slutar i ett beslut istället för en anteckning.

Bekräfta gränssnittet som protokollet behöver

OpenVPN över TUN kräver teckenenheten och kärnmodulen bakom den; WireGuard kräver sitt eget kärnstöd eller en användarrymdsimplementation med matchande förväntningar. Hanterade containrar kan dela en värdkärna som aldrig exponerar enheten, och vissa plattformar förbjuder att skapa tunnelgränssnitt helt, oavsett vad som är installerat.

Testa förmågan istället för att läsa en supportsida, eftersom marknadsföringsetiketter ändras snabbare än de underliggande gränserna. En funktionslista skriven för en plan beskriver kanske inte kärnan som gästen faktiskt kör på. Två korta kommandon svarar på frågan för de vanligast använda protokollen, och båda städar efter sig. Kommandona nedan skapar ingenting beständigt och tas bort omedelbart.

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

En vägran på det första paret betyder att TUN inte är tillgängligt och att OpenVPN:s standardläge inte kan starta; en vägran på den sista raden betyder att WireGuard-kärngränssnittet saknas. Kärnans TUN/TAP-dokumentation beskriver enheten som den första kontrollen prövar. Ingen av de två felen åtgärdas genom att installera om VPN-paketet.

Kom ihåg att den inkommande vägen har två ägare

Leverantörens nätverksregler och gästens brandvägg är separata system, och trafiken måste överleva båda. En lyssnare bunden på gästen betyder ingenting om leverantörens säkerhetsgrupp släpper porten, och en öppen leverantörsregel gör ingenting om gästen avvisar paketet. Verifiera lyssnaren, sedan gästens regler, sedan leverantörens panel, i den ordningen, och bekräfta både protokollet och portnumret. Att hoppa direkt till leverantörens panel är hur folk öppnar ett intervall de inte behövde.

UDP är det vanliga offret: många plattformar tillåter TCP som standard och behandlar UDP-regler som en separat post. Om instansen sitter bakom leverantörens NAT istället för att ha en offentlig adress blir portvidarebefordran på leverantörssidan en tredje konfiguration att stämma av.

Planera returvägen, inte bara utgången

Tjänst med full tunnel kräver vidarebefordran aktiverad, ett översättnings- eller routingmönster för klienttrafik och en returväg som når klientpoolen. Att öppna en lyssnare ger inget av detta. En tunnel som etableras men inte bär nyttig trafik misslyckas vanligtvis här istället för vid autentiseringen. Behandla ett lyckat handskakning som början på diagnosen, inte slutet.

Skriv planen som tre konkreta beslut: vilket källintervall klienterna får, hur deras trafik går ut mot internet och hur svar hittar vägen tillbaka. Bekräfta sedan att kärnan instämmer i planen innan du testar en klient, så att en tyst avvikelse inte förväxlas med ett fel på klientsidan.

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

Avgör IPv6-frågan uttryckligen

IPv6 kommer via flera mekanismer som beter sig olika för en gateway: en adress på instansen, ett routat prefix eller ingenting. Bara ett routat prefix låter servern ge adresser till klienter på det vanliga sättet. Antagandet att en fungerande IPv6-adress på värden innebär ett användbart klientprefix är ett fel som dyker upp senare som halvt bruten anslutning. Det är den typen av fel som överlever varje test som bara görs med IPv4.

Om leverantören inte routar något prefix, avgör om tunneln bara är IPv4 och om klienterna ska få veta det. En dokumenterad frånvaro är säkrare än en delvis konfiguration som tyst skickar IPv6-destinationer i ett svart hål för anslutna användare.

Bevisa det från en extern klient

Lokal tjänstestatus beskriver en process på en värd. Det användbara testet är en auktoriserad klient på ett annat nätverk, som ansluter med profilen du avser att distribuera, sedan når en applikation och löser ett namn. Anslut igen en gång också, eftersom en tunnel som bara fungerar vid första försöket inte uppfyller kravet som betyder mest i praktiken.

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

Håll det operativa grunden bredvid testet: plats för uppdateringar, begränsade loggar, administrativ åtkomst som inte beror på tunneln, en återställningskonsol och en anteckning om vad som händer med klientprofiler när instansen byggs om och dess offentliga adress ändras. Om ett nödvändigt gränssnitt eller vidarebefordransmodell helt enkelt inte är tillgängligt kommer ingen ändring på klientsidan att ordna det, och det ärliga nästa steget är en annan instanstyp istället för mer konfiguration.