Wat ’n VPS moet toelaat voordat dit jou VPN kan huisves

Die instansie begin, pakketinstallasies slaag, en die diens rapporteer selfs ’n lopende toestand, maar niks verbind nie. Dié patroon is algemeen op virtuele private bedieners, want ’n gas wat gemaklik die internet bereik, kan steeds nie die koppelvlak skep wat jou protokol wil hê nie. Vyf kontroles skei ’n gasheer wat ’n tonnel kan diens van een wat net gereed lyk, en die eerste wat misluk, verduidelik gewoonlik alles daarna. Elkeen is goedkoop om te hardloop en eindig in ’n besluit eerder as ’n nota.

Bevestig die koppelvlak wat die protokol nodig het

OpenVPN oor TUN het die karaktertoestel en die kernmodule daarby nodig; WireGuard het sy eie kernondersteuning of ’n gebruikersruimte-implementering met ooreenstemmende verwagtinge nodig. Bestuurde houers kan ’n gasheerkern deel wat nooit die toestel blootstel nie, en sommige platforms verbied dit heeltemal om tonnelkoppelvlakke te skep, ongeag wat geïnstalleer is.

Toets vermoë in plaas daarvan om ’n ondersteuningsblad te lees, want bemarkingsetikette verander vinniger as die onderliggende beperkings. ’n Kenmerklys vir een plan beskryf dalk nie die kern waarop die gas werklik loop nie. Twee kort opdragte beantwoord die vraag vir die protokolle wat algemeen gebruik word, en albei ruim ná hulleself op. Die opdragte hieronder skep niks blywends nie en word dadelik verwyder.

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

’n Weiering op die eerste paar beteken TUN is onbeskikbaar en OpenVPN se verstekmodus kan nie begin nie; ’n weiering op die laaste reël beteken die WireGuard-kernkoppelvlak ontbreek. Die kern-TUN/TAP-dokumentasie beskryf die toestel wat die eerste kontrole toets. Nie een van die twee foute word deur herinstallering van die VPN-pakket reggemaak nie.

Onthou dat die inkomende pad twee eienaars het

Die verskaffer se netwerkreëls en die gas se brandmuur is aparte stelsels, en verkeer moet albei oorleef. ’n Luisteraar wat op die gas gebind is, beteken niks as die verskaffer se veiligheidsgroep die poort laat val nie, en ’n oop verskafferreël doen niks as die gas die pakkie verwerp nie. Verifieer die luisteraar, dan die gasreëls, dan die verskafferpaneel, in daardie volgorde, en bevestig die protokol sowel as die poortnommer. Om eerste na die verskafferpaneel te spring, is hoe mense ’n reeks oopmaak wat hulle nie nodig gehad het nie.

UDP is die algemene slagoffer: baie platforms laat TCP by verstek toe en behandel UDP-reëls as ’n aparte inskrywing. As die instansie agter die verskaffer se NAT sit eerder as om ’n openbare adres te hou, word poortaanstuur aan die verskafferkant ’n derde konfigurasie om te versoen.

Beplan die terugpad, nie net die uitgang nie

Voltonnel-diens benodig aanstuur geaktiveer, ’n vertalings- of roeteringskema vir kliëntverkeer, en ’n terugpad wat die kliëntpoel bereik. Om ’n luisteraar oop te maak, lewer niks hiervan nie. ’n Tonnel wat vestig maar geen nuttige verkeer dra nie, faal gewoonlik hier eerder as by verifikasie. Behandel ’n suksesvolle handdruk as die begin van die diagnose, nie die einde daarvan nie.

Skryf die plan as drie konkrete besluite: watter bronreeks kliënte ontvang, hoe hul verkeer na die internet vertrek, en hoe antwoorde terugvind. Bevestig dan dat die kern met die plan saamstem voordat jy ’n kliënt toets, sodat ’n stille wanverhouding nie as ’n kliëntfout beskou word nie.

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

Besluit die IPv6-verhaal eksplisiet

IPv6 kom deur verskeie meganismes wat vir ’n poort anders werk: ’n adres op die instansie, ’n geroete voorvoegsel, of glad niks. Net ’n geroete voorvoegsel laat die bediener adresse op die gewone manier aan kliënte gee. Om te aanvaar dat ’n werkende IPv6-adres op die gasheer ’n bruikbare kliëntvoorvoegsel impliseer, is ’n fout wat later opduik as halfgebreekte verbinding. Dit is die soort fout wat elke toets oorleef wat net met IPv4 gedoen word.

As die verskaffer geen voorvoegsel roet nie, besluit of die tonnel slegs IPv4 is en of kliënte daarvan vertel moet word. ’n Gedokumenteerde afwesigheid is veiliger as ’n gedeeltelike konfigurasie wat IPv6-bestemmings vir verbinde gebruikers stilweg in ’n swartgat laat val.

Bewys dit vanaf ’n eksterne kliënt

Plaaslike diensstatus beskryf een proses op een gasheer. Die nuttige toets is ’n gemagtigde kliënt op ’n ander netwerk, wat met die profiel verbind wat jy van plan is om te versprei, dan ’n toepassing bereik en ’n naam oplos. Herverbind ook een keer, want ’n tonnel wat net met die eerste poging werk, faal die vereiste wat in die praktyk die meeste saak maak.

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

Hou die operasionele basiese dinge by die toets: ruimte vir opdaterings, begrensde logs, administratiewe toegang wat nie van die tonnel afhang nie, ’n herstelkonsole, en ’n nota oor wat met kliëntprofiele gebeur wanneer die instansie herbou word en sy openbare adres verander. As ’n vereiste koppelvlak of aanstuurmodel eenvoudig nie beskikbaar is nie, sal geen kliëntkantverandering dit verskaf nie, en die eerlike volgende stap is ’n ander instansietipe eerder as meer konfigurasie.