Zer onartu behar du VPS batek zure VPN-a ostatatzeko

Instantzia abiarazi egiten da, paketeen instalazioek arrakasta dute, eta zerbitzuak exekuzio-egoera ere jakinarazten du, baina ezer ez da konektatzen. Eredu hori ohikoa da zerbitzari pribatu birtualetan, internetera erosotasunez iristen den gonbidatu bat gai baitaiteke zure protokoloak nahi duen interfazea sortzeko. Bost egiaztapenek tunel bat zerbitza dezakeen ostalaria soilik prest dagoen itxura duenetik bereizten dute, eta huts egiten duen lehen egiaztapenak normalean ondorengo guztia azaltzen du. Bakoitza merkea da exekutatzeko eta erabaki batean amaitzen da, ohar batean beharrean.

Berretsi protokoloak behar duen interfazea

OpenVPN TUN gainean egoteko karaktere-gailua eta haren atzeko kernel modulua behar ditu; WireGuarden bere kernel sostengua edo erabiltzaile-espazioko inplementazio bat behar du itxaropen egokiekin. Kudeatutako edukiontziek gailua inoiz erakusten ez duen ostalari-kernel bat parteka dezakete, eta plataforma batzuek tunel-interfazeak sortzea erabat debekatzen dute, instalatuta dagoen edozein dela ere.

Probatu gaitasuna, ez irakurri sostengu-orri bat, marketin-etiketek azpiko mugek baino azkarrago aldatzen baitira. Plan baterako idatzitako funtzio-zerrenda batek agian ez du deskribatzen gonbidatua benetan exekutatzen den kernela. Bi komando laburrek erabilera arrunteko protokoloentzako galderari erantzuten diote, eta biek beren atzetik garbitzen dute. Beheko komandoek ez dute ezer iraunkorrik sortzen eta berehala kentzen dira.

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

Lehen bikotean uko egiteak TUN ez dagoela esan nahi du eta OpenVPNren modu lehenetsiak ezin duela abiarazi; azken lerroan uko egiteak WireGuarden kernel interfazea falta dela esan nahi du. Kernelaren TUN/TAP dokumentazioak lehen egiaztapenak probatzen duen gailua deskribatzen du. Bi hutsegite horietako bat ere ez da konpontzen VPN paketea berriro instalatuta.

Gogoratu sarrera-bideak bi jabe dituela

Hornitzailearen sare-arauak eta gonbidatuaren suebakia sistema bereiziak dira, eta trafikoak biak gainditu behar ditu. Gonbidatuan lotutako entzule batek ez du ezer esan nahi hornitzailearen segurtasun-taldeak ataka botatzen badu, eta hornitzailearen arau ireki batek ez du ezer egiten gonbidatuak paketea ukatzen badu. Egiaztatu entzulea, gero gonbidatuaren arauak, gero hornitzailearen panela, ordena horretan, eta berretsi protokoloa zein ataka-zenbakia. Hornitzailearen panelera zuzenean jauzi egitea da jendeak behar ez zuen barruti bat irekitzen amaitzeko modua.

UDP ohiko biktima da: plataforma askok TCP onartzen dute lehenespenez eta UDP arauak sarrera bereizi gisa tratatzen dituzte. Instantzia hornitzailearen NAT atzean badago helbide publiko bat eduki beharrean, hornitzailearen aldeko ataka-birbidalketa adostu beharreko hirugarren konfigurazio bihurtzen da.

Planifikatu itzulera-bidea, ez irteera soilik

Tunel osoko zerbitzuak birbidalketa gaituta, bezeroen trafikoaren itzulpen edo bideratze eskema bat eta bezeroen multzora iristen den itzulera-bide bat behar ditu. Entzule bat irekitzeak ez du horietako bat ere ematen. Ezarri baina trafiko erabilgarririk eramaten ez duen tunel batek normalean hemen egiten du huts, ez autentifikazioan. Hartu eskuko keinu arrakastatsua diagnostikoaren hasieratzat, ez haren amaitutzat.

Idatzi plana hiru erabaki zehatz gisa: bezeroek zer iturburu-barruti jasotzen duten, haien trafikoak nola irteten duen internet aldera eta nola aurkitzen duten erantzunek itzulera-bidea. Ondoren berretsi kernelak planarekin ados dagoela bezero bat probatu aurretik, isilikako desadostasuna bezeroaren aldeko akats ez dadin hartu.

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

Erabaki IPv6 kontua espresuki

IPv6 hainbat mekanismoren bidez iristen da, atebide batentzat modu desberdinean jokatzen dutenak: instantziako helbide bat, bideratutako aurrizki bat edo ezer ez. Bideratutako aurrizki batek soilik uzten dio zerbitzariari bezeroei helbideak ohiko moduan ematen. Ostalarian funtzionatzen duen IPv6 helbide batek bezero-aurrizki erabilgarria esan nahi duela pentsatzea geroago erdi hautsitako konektibitate gisa agertzen den akatsa da. IPv4 bakarrarekin egindako proba guztiak gainditzen dituen akats mota da.

Hornitzaileak aurrizkirik bideratzen ez badu, erabaki tunela IPv4 soilik den eta bezeroei hori esan behar zaien. Dokumentatutako ez-egotea seguruagoa da konektatutako erabiltzaileentzat IPv6 helmugak isilka zulo beltzera botatzen dituen konfigurazio partzial bat baino.

Egiaztatu kanpoko bezero batetik

Tokiko zerbitzu-egoerak ostalari bateko prozesu bat deskribatzen du. Proba erabilgarria beste sare bateko bezero baimendu bat da, banatzeko asmoa duzun profilekin konektatzen dena, gero aplikazio batera iristen dena eta izen bat ebazten duena. Berriro konektatu behin ere, lehen saiakuntzan soilik funtzionatzen duen tunel batek praktikan gehien axola duen baldintza ez baitu betetzen.

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

Eduki oinarri operatiboak probaren ondoan: eguneraketarako tokia, mugatutako erregistroak, tunelaren mende ez dagoen administrazio-sarbidea, berreskuratze-kontsola bat, eta instantzia berreraikitzen denean eta haren helbide publikoa aldatzen denean bezero-profilen zer gertatzen den jakiteko ohar bat. Beharrezko interfaze edo birbidalketa-eredu bat besterik ez badago, bezeroaren aldeko aldaketak ez du emango, eta hurrengo urrats zintzoa beste instantzia mota bat da, ez konfigurazio gehiago.