Kva ein VPS må tillate før han kan vera vert for VPN-en din

Instansen startar, pakkeinstallasjonar lukkast, og tenesta rapporterer jamvel ein køyrande tilstand, men ingenting blir kopla til. Dette mønsteret er vanleg på virtuelle private servarar, fordi ein gjest som lett når internett framleis kan vera ute av stand til å oppretta grensesnittet protokollen din vil ha. Fem kontrollar skil ein vert som kan tena ein tunnel frå ein som berre ser klar ut, og den første kontrollen som feilar forklarer vanlegvis alt etterpå. Kvar av dei er billeg å køyra og endar i eit vedtak i staden for eit notat.

Stadfest grensesnittet protokollen treng

OpenVPN over TUN treng teikneininga og kjernemodulen bak henne; WireGuard treng si eiga kjernestøtte eller ein brukarromsimplementasjon med samsvarande forventningar. Styrte containarar kan dela ein vertskjerne som aldri eksponerer eininga, og nokre plattformer forbyr å oppretta tunnelgrensesnitt heilt, same kva som er installert.

Test evna i staden for å lesa ei støtteside, fordi marknadsføringsetikettar endrar seg raskare enn dei underliggjande grensene. Ei funksjonsliste skriven for éin plan skildrar kanskje ikkje kjernen gjesten faktisk køyrer på. To korte kommandoar svarar på spørsmålet for dei vanleg brukte protokollane, og båe ryddar opp etter seg. Kommandoane nedanfor opprettar ingenting permanent og blir fjerna med det same.

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

Ei avvising på det første paret tyder at TUN ikkje er tilgjengeleg og at standardmodusen til OpenVPN ikkje kan starta; ei avvising på den siste linja tyder at WireGuard-kjernegrensesnittet manglar. Kjernens TUN/TAP-dokumentasjon skildrar eininga den første kontrollen prøver. Ingen av dei to feila blir retta ved å installera VPN-pakken på nytt.

Hugs at den innkommande vegen har to eigarar

Nettverksreglane til leverandøren og brannmuren til gjesten er separate system, og trafikken må overleva båe. Ein lyttar bunden på gjesten tyder ingenting om sikkerheitsgruppa til leverandøren slepp porten, og ein open leverandørregel gjer ingenting om gjesten avviser pakken. Stadfest lyttaren, deretter reglane til gjesten, deretter leverandørpanelet, i den rekkjefølgja, og stadfest både protokollen og portnummeret. Å hoppa rett til leverandørpanelet er korleis folk endar med å opna eit område dei ikkje trongde.

UDP er det vanlege offeret: mange plattformer tillèt TCP som standard og handsamar UDP-reglar som ein eigen oppføring. Om instansen sit bak NAT-en til leverandøren i staden for å ha ei offentleg adresse, blir portvidaresending på leverandørsida ein tredje konfigurasjon som må samsvarast.

Planlegg returvegen, ikkje berre utgangen

Teneste med full tunnel treng vidaresending slått på, eit omsetjings- eller rutordning for klienttrafikk og ein returveg som når klientpoolen. Å opna ein lyttar gir ingenting av dette. Ein tunnel som blir etablert men ikkje ber nyttig trafikk, feilar vanlegvis her i staden for ved autentisering. Behandle eit vellukka handtrykk som starten på diagnosen, ikkje slutten.

Skriv planen som tre konkrete vedtak: kva kjeldeområde klientane får, korleis trafikken deira går ut mot internett, og korleis svar finn vegen tilbake. Stadfest deretter at kjernen er samd i planen før du testar ein klient, slik at eit stille avvik ikkje blir forveksla med ein feil på klientsida.

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

Avgjer IPv6-spørsmålet eksplisitt

IPv6 kjem via fleire mekanismar som oppfører seg ulikt for ein gateway: ei adresse på instansen, eit ruta prefiks eller ingenting. Berre eit ruta prefiks lèt serveren gi adresser til klientar på den vanlege måten. Føresetnaden om at ei fungerande IPv6-adresse på verten tyder eit brukbart klientprefiks, er ein feil som dukkar opp seinare som halvbroten tilkopling. Det er den typen feil som overlever kvar test som berre blir gjort med IPv4.

Om leverandøren ikkje rutar noko prefiks, avgjer om tunnelen berre er IPv4 og om klientane skal få vita det. Eit dokumentert fråvær er tryggare enn ein delvis konfigurasjon som stille sender IPv6-mål i eit svart hol for tilkopla brukarar.

Prov det frå ein ekstern klient

Lokal tenestestatus skildrar éin prosess på éin vert. Den nyttige testen er ein autorisert klient på eit anna nettverk, som koplar til med profilen du har tenkt å distribuera, deretter når ein applikasjon og løyser eit namn. Kopla til på nytt ein gong òg, fordi ein tunnel som berre verkar ved første forsøk ikkje oppfyller kravet som tel 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

Hald det operasjonelle grunnlaget ved sida av testen: plass til oppdateringar, avgrensa loggar, administrativ tilgang som ikkje er avhengig av tunnelen, ein gjenopprettingskonsoll og eit notat om kva som skjer med klientprofilar når instansen blir bygd på nytt og den offentlege adressa hans endrar seg. Om eit nødvendig grensesnitt eller vidaresendingsmodell rett og slett ikkje er tilgjengeleg, vil inga endring på klientsida skaffa det, og det ærlege neste steget er ein annan instanstype i staden for meir konfigurasjon.