Mitä VPS:n on sallittava ennen kuin se voi ylläpitää VPN:ääsi

Instanssi käynnistyy, pakettien asennukset onnistuvat ja palvelu ilmoittaa jopa käynnissä olevasta tilasta, mutta mikään ei yhdisty. Tämä kuvio on yleinen virtuaalisilla yksityispalvelimilla, koska vieras, joka pääsee mukavasti internetiin, voi silti olla kykenemätön luomaan liitännän, jota protokollasi vaatii. Viisi tarkistusta erottavat isännän, joka pystyy palvelemaan tunnelia, siitä, joka vain näyttää valmiilta, ja ensimmäinen epäonnistuva tarkistus yleensä selittää kaiken sen jälkeen. Jokainen on halpa ajaa ja päättyy päätökseen, ei muistiinpanoon.

Varmista liitäntä, jonka protokolla tarvitsee

OpenVPN TUN:n päällä tarvitsee merkkilaitteen ja sen takana olevan ytimen moduulin; WireGuard tarvitsee oman ydintukensa tai käyttäjäavaruuden toteutuksen vastaavin odotuksin. Hallitut kontit voivat jakaa isäntäytimen, joka ei koskaan paljasta laitetta, ja jotkin alustat kieltävät tunneliliitäntöjen luomisen kokonaan riippumatta siitä, mitä on asennettu.

Testaa kyvykkyyttä sen sijaan, että luet tukisivua, koska markkinointitarrat muuttuvat nopeammin kuin taustalla olevat rajat. Yhdelle suunnitelmalle kirjoitettu ominaisuusluettelo ei välttämättä kuvaa ydintä, jolla vieras todella toimii. Kaksi lyhyttä komentoa vastaavat kysymykseen yleisesti käytetyille protokollille, ja molemmat siivoavat jälkensä. Alla olevat komennot eivät luo mitään pysyvää ja poistetaan heti.

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

Hylkäys ensimmäisessä parissa tarkoittaa, että TUN ei ole käytettävissä eikä OpenVPN:n oletustila voi käynnistyä; hylkäys viimeisellä rivillä tarkoittaa, että WireGuardin ydinaliitäntä puuttuu. Ytimen TUN/TAP-dokumentaatio kuvaa laitteen, jota ensimmäinen tarkistus harjoittaa. Kumpaakaan epäonnistumista ei korjata asentamalla VPN-paketti uudelleen.

Muista, että saapuvalla polulla on kaksi omistajaa

Palveluntarjoajan verkkosäännöt ja vieraan palomuuri ovat erillisiä järjestelmiä, ja liikenteen on selvittävä molemmista. Vieraalle sidottu kuuntelija ei merkitse mitään, jos palveluntarjoajan suojausryhmä pudottaa portin, eikä avoin palveluntarjoajan sääntö tee mitään, jos vieras hylkää paketin. Tarkista kuuntelija, sitten vieraan säännöt, sitten palveluntarjoajan paneeli, tässä järjestyksessä, ja varmista sekä protokolla että portin numero. Suoraan palveluntarjoajan paneeliin hyppääminen on tapa, jolla ihmiset avaavat alueen, jota he eivät tarvinneet.

UDP on tavallinen uhri: monet alustat sallivat TCP:n oletuksena ja käsittelevät UDP-säännöt erillisenä merkintänä. Jos instanssi on palveluntarjoajan NAT:n takana sen sijaan, että sillä olisi julkinen osoite, portin edelleenlähetys palveluntarjoajan puolella muuttuu kolmanneksi yhdistettäväksi kokoonpanoksi.

Suunnittele paluupolku, älä vain lähtöä

Täystunnelin palvelu tarvitsee käytössä olevan edelleenlähetyksen, asiakasliikenteen käännös- tai reititysskeeman ja paluupolun, joka saavuttaa asiakasjoukon. Kuuntelijan avaaminen ei anna yhtään näistä. Tunneli, joka muodostuu mutta ei kuljeta hyödyllistä liikennettä, epäonnistuu yleensä täällä, ei todennuksessa. Kohtele onnistunutta kättelyä diagnoosin alkuna, ei sen loppuna.

Kirjoita suunnitelma kolmena konkreettisena päätöksenä: minkä lähdealueen asiakkaat saavat, miten heidän liikenteensä lähtee internetiin ja miten vastaukset löytävät paluutien. Varmista sitten, että ydin on suunnitelman kanssa samaa mieltä ennen asiakkaan testaamista, jotta hiljaista ristiriitaa ei luulla asiakaspuolen viaksi.

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

Päätä IPv6-kysymys nimenomaisesti

IPv6 tulee useiden mekanismien kautta, jotka käyttäytyvät yhdyskäytävälle eri tavoin: osoite instanssilla, reititetty etuliite tai ei mitään. Vain reititetty etuliite antaa palvelimen antaa osoitteita asiakkaille tavallisella tavalla. Oletus, että isännällä toimiva IPv6-osoite tarkoittaa käyttökelpoista asiakasetuliitettä, on virhe, joka ilmenee myöhemmin puoliksi rikkinäisenä yhteytenä. Se on sellainen vika, joka selviää jokaisesta vain IPv4:llä tehdystä testistä.

Jos palveluntarjoaja ei reititä yhtään etuliitettä, päätä, onko tunneli vain IPv4 ja pitäisikö asiakkaille kertoa siitä. Dokumentoitu puuttuminen on turvallisempaa kuin osittainen kokoonpano, joka lähettää IPv6-kohteet hiljaa mustaan aukkoon yhdistetyille käyttäjille.

Todista se ulkoiselta asiakkaalta

Paikallinen palvelutila kuvaa yhtä prosessia yhdellä isännällä. Hyödyllinen testi on valtuutettu asiakas toisessa verkossa, joka yhdistää profiililla, jonka aiot jakaa, saavuttaa sitten sovelluksen ja ratkaisee nimen. Yhdistä myös kerran uudelleen, koska tunneli, joka toimii vain ensimmäisellä yrityksellä, epäonnistuu vaatimuksessa, jolla on käytännössä eniten merkitystä.

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

Pidä operatiiviset perusteet testin rinnalla: tilaa päivityksille, rajatut lokit, hallinnollinen pääsy, joka ei riipu tunnelista, palautuskonsoli ja muistiinpano siitä, mitä asiakasprofiileille tapahtuu, kun instanssi rakennetaan uudelleen ja sen julkinen osoite muuttuu. Jos vaadittu liitäntä tai edelleenlähetysmalli yksinkertaisesti puuttuu, mikään asiakaspuolen muutos ei tarjoa sitä, ja rehellinen seuraava askel on toisenlainen instanssi, ei lisää kokoonpanoa.