Hvad en VPS skal tillade, før den kan hoste din VPN

Instansen starter, pakkeinstallationer lykkes, og tjenesten rapporterer endda en kørende tilstand, men intet forbinder. Det mønster er almindeligt på virtuelle private servere, fordi en gæst, der komfortabelt når internettet, stadig kan være ude af stand til at oprette det interface, din protokol vil have. Fem kontroller adskiller en vært, der kan betjene en tunnel, fra en der kun ser klar ud, og den første kontrol, der fejler, forklarer normalt alt derefter. Hver af dem er billig at køre og ender i en beslutning frem for en note.

Bekræft det interface, protokollen kræver

OpenVPN over TUN kræver tegngiverenheden og kernelmodulet bag den; WireGuard kræver sin egen kernestøtte eller en brugerspace-implementering med tilsvarende forventninger. Administrerede containere deler muligvis en værtskerne, der aldrig eksponerer enheden, og nogle platforme forbyder helt at oprette tunnelinterfaces, uanset hvad der er installeret.

Test evnen i stedet for at læse en supportside, fordi marketingetiketter ændrer sig hurtigere end de underliggende grænser. En funktionsliste skrevet til én plan beskriver måske ikke den kerne, gæsten faktisk kører på. To korte kommandoer besvarer spørgsmålet for de almindeligt anvendte protokoller, og begge rydder op efter sig. Kommandoerne nedenfor opretter intet permanent og fjernes med det samme.

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 afvisning på det første par betyder, at TUN ikke er tilgængelig, og at OpenVPNs standardtilstand ikke kan starte; en afvisning på den sidste linje betyder, at WireGuard-kernelinterfacet mangler. kernens TUN/TAP-dokumentation beskriver den enhed, den første kontrol prøver. Ingen af de to fejl repareres ved at geninstallere VPN-pakken.

Husk, at den indgående vej har to ejere

Udbyderens netværksregler og gæstens firewall er separate systemer, og trafik skal overleve begge. En lytter bundet på gæsten betyder intet, hvis udbyderens sikkerhedsgruppe dropper porten, og en åben udbyderregel gør intet, hvis gæsten afviser pakken. Bekræft lytteren, derefter gæstens regler, derefter udbyderens panel, i den rækkefølge, og bekræft både protokollen og portnummeret. At springe direkte til udbyderens panel er, hvordan folk ender med at åbne et interval, de ikke havde brug for.

UDP er det sædvanlige offer: mange platforme tillader TCP som standard og behandler UDP-regler som en separat post. Hvis instansen sidder bag udbyderens NAT i stedet for at have en offentlig adresse, bliver portvideresendelse på udbyderens side en tredje konfiguration, der skal afstemmes.

Planlæg returvejen, ikke kun udgangen

Fuld tunnel-tjeneste kræver videresendelse aktiveret, en oversættelses- eller routingordning for klienttrafik og en returvej, der når klientpuljen. At åbne en lytter giver ingen af disse. En tunnel, der etableres, men ikke bærer nyttig trafik, fejler normalt her frem for ved godkendelse. Betragt et vellykket håndtryk som starten på diagnosen, ikke dens slutning.

Skriv planen som tre konkrete beslutninger: hvilket kildeinterval klienter får, hvordan deres trafik forlader mod internettet, og hvordan svar finder vej tilbage. Bekræft derefter, at kernen er enig i planen, før du tester en klient, så en tavs uoverensstemmelse ikke forveksles med en fejl på klientsiden.

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

Tag stilling til IPv6 eksplicit

IPv6 kommer via flere mekanismer, der opfører sig forskelligt for en gateway: en adresse på instansen, et rutet præfiks eller intet. Kun et rutet præfiks lader serveren give adresser til klienter på den sædvanlige måde. At antage, at en fungerende IPv6-adresse på værten betyder et brugbart klientpræfiks, er en fejl, der senere dukker op som halvt brudt forbindelse. Det er den slags fejl, der overlever enhver test, der kun udføres med IPv4.

Hvis udbyderen ikke ruter noget præfiks, så afgør, om tunnelen kun er IPv4, og om klienterne skal have det at vide. Et dokumenteret fravær er sikrere end en delvis konfiguration, der tavst sender IPv6-destinationer i et sort hul for tilsluttede brugere.

Bevis det fra en ekstern klient

Lokal tjenestestatus beskriver én proces på én vært. Den nyttige test er en autoriseret klient på et andet netværk, der forbinder med den profil, du agter at distribuere, derefter når en applikation og opløser et navn. Genopret forbindelsen en gang også, fordi en tunnel, der kun virker ved første forsøg, fejler det krav, der betyder mest i praksis.

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

Hold den operationelle basis ved siden af testen: plads til opdateringer, begrænsede logfiler, administrativ adgang, der ikke afhænger af tunnelen, en gendannelseskonsol og en note om, hvad der sker med klientprofiler, når instansen genopbygges, og dens offentlige adresse ændres. Hvis et krævet interface eller videresendelsesmodel simpelthen ikke findes, vil ingen ændring på klientsiden skaffe det, og det ærlige næste skridt er en anden instanstype frem for mere konfiguration.