Hva en VPS må tillate før den kan være vert for VPN-en din

Instansen starter, pakkeinstallasjoner lykkes, og tjenesten rapporterer til og med en kjørende tilstand, men ingenting kobles til. Dette mønsteret er vanlig på virtuelle private servere, fordi en gjest som enkelt når internett fortsatt kan være ute av stand til å opprette grensesnittet protokollen din vil ha. Fem kontroller skiller en vert som kan betjene en tunnel fra en som bare ser klar ut, og den første kontrollen som feiler forklarer vanligvis alt etterpå. Hver av dem er billig å kjøre og ender i en beslutning istedenfor et notat.

Bekreft grensesnittet protokollen trenger

OpenVPN over TUN trenger tegntegnet og kjernemodulen bak det; WireGuard trenger sin egen kjernestøtte eller en brukerromsimplementasjon med samsvarende forventninger. Administrerte containere kan dele en vertskjerne som aldri eksponerer enheten, og noen plattformer forbyr å opprette tunnelgrensesnitt helt, uansett hva som er installert.

Test evnen istedenfor å lese en støtteside, fordi markedsføringsetiketter endres raskere enn de underliggende grensene. En funksjonsliste skrevet for én plan beskriver kanskje ikke kjernen gjesten faktisk kjører på. To korte kommandoer svarer på spørsmålet for de vanlig brukte protokollene, og begge rydder opp etter seg. Kommandoene nedenfor oppretter ingenting permanent og fjernes umiddelbart.

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 avvisning på det første paret betyr at TUN ikke er tilgjengelig og at standardmodusen til OpenVPN ikke kan starte; en avvisning på den siste linjen betyr at WireGuard-kjernegrensesnittet mangler. Kjernens TUN/TAP-dokumentasjon beskriver enheten den første kontrollen prøver. Ingen av de to feilene rettes ved å installere VPN-pakken på nytt.

Husk at den innkommende veien har to eiere

Leverandørens nettverksregler og gjestens brannmur er separate systemer, og trafikken må overleve begge. En lytter bundet på gjesten betyr ingenting hvis leverandørens sikkerhetsgruppe slipper porten, og en åpen leverandørregel gjør ingenting hvis gjesten avviser pakken. Bekreft lytteren, deretter gjestens regler, deretter leverandørpanelet, i den rekkefølgen, og bekreft både protokollen og portnummeret. Å hoppe rett til leverandørpanelet er hvordan folk ender med å åpne et område de ikke trengte.

UDP er det vanlige offeret: mange plattformer tillater TCP som standard og behandler UDP-regler som en egen oppføring. Hvis instansen sitter bak leverandørens NAT istedenfor å ha en offentlig adresse, blir portvideresending på leverandørsiden en tredje konfigurasjon som må avstemmes.

Planlegg returveien, ikke bare utgangen

Tjeneste med full tunnel trenger videresending aktivert, et oversettelses- eller rutordning for klienttrafikk og en returvei som når klientpoolen. Å åpne en lytter gir ingenting av dette. En tunnel som etableres men ikke bærer nyttig trafikk, feiler vanligvis her istedenfor ved autentisering. Behandle et vellykket håndtrykk som starten på diagnosen, ikke slutten.

Skriv planen som tre konkrete beslutninger: hvilket kildeområde klientene får, hvordan trafikken deres går ut mot internett, og hvordan svar finner veien tilbake. Bekreft deretter at kjernen er enig i planen før du tester en klient, slik at et stille avvik ikke forveksles med en feil på klientsiden.

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

Avgjør IPv6-spørsmålet eksplisitt

IPv6 kommer via flere mekanismer som oppfører seg ulikt for en gateway: en adresse på instansen, et rutet prefiks eller ingenting. Bare et rutet prefiks lar serveren gi adresser til klienter på den vanlige måten. Antakelsen om at en fungerende IPv6-adresse på verten betyr et brukbart klientprefiks, er en feil som dukker opp senere som halvbrutt tilkobling. Det er den typen feil som overlever enhver test som bare gjøres med IPv4.

Hvis leverandøren ikke ruter noe prefiks, avgjør om tunnelen bare er IPv4 og om klientene skal få vite det. Et dokumentert fravær er tryggere enn en delvis konfigurasjon som stille sender IPv6-destinasjoner i et svart hull for tilkoblede brukere.

Bevis det fra en ekstern klient

Lokal tjenestestatus beskriver én prosess på én vert. Den nyttige testen er en autorisert klient på et annet nettverk, som kobler til med profilen du har tenkt å distribuere, deretter når en applikasjon og løser et navn. Koble til på nytt en gang også, fordi en tunnel som bare virker ved første forsøk ikke oppfyller kravet som betyr 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 det operasjonelle grunnlaget ved siden av testen: plass til oppdateringer, begrensede logger, administrativ tilgang som ikke avhenger av tunnelen, en gjenopprettingskonsoll og et notat om hva som skjer med klientprofiler når instansen bygges på nytt og dens offentlige adresse endres. Hvis et nødvendig grensesnitt eller videresendingsmodell rett og slett ikke er tilgjengelig, vil ingen endring på klientsiden skaffe det, og det ærlige neste steget er en annen instanstype istedenfor mer konfigurasjon.