Kion VPS devas permesi antaŭ ol ĝi povas gastigi vian VPN

La instanco ekfunkcias, pakaĵaj instaladoj sukcesas, kaj la servo eĉ raportas funkcian staton, tamen nenio konektiĝas. Tiu ŝablono oftas ĉe virtualaj privataj serviloj, ĉar gasto, kiu komforte atingas la interreton, ankoraŭ povas esti nekapabla krei la interfacon, kiun via protokolo postulas. Kvin kontroloj apartigas gastiganton, kiu povas servi tunelon, de tiu, kiu nur ŝajnas preta, kaj la unua malsukcesa kontrolo kutime klarigas ĉion post ĝi. Ĉiu estas malmultekosta por lanĉi kaj finiĝas per decido, ne per noto.

Konfirmu la interfacon, kiun la protokolo bezonas

OpenVPN super TUN bezonas la signan aparaton kaj la kernan modulon malantaŭ ĝi; WireGuard bezonas propran kernan subtenon aŭ uzantspacan realigon kun kongruaj atendoj. Administrataj ujoj povas kunhavigi gastigantan kernon, kiu neniam elmontras la aparaton, kaj iuj platformoj tute malpermesas krei tunelajn interfacojn sendepende de tio, kio estas instalita.

Testu la kapablon anstataŭ legi subtenan paĝon, ĉar merkatikaj etikedoj ŝanĝiĝas pli rapide ol la subaj limoj. Trajto-listo verkita por unu plano eble ne priskribas la kernon, sur kiu la gasto efektive funkcias. Du mallongaj komandoj respondas la demandon por la kutime uzataj protokoloj, kaj ambaŭ purigas post si. La subaj komandoj kreas nenion daŭran kaj estas forigitaj tuj.

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

Rifuzo ĉe la unua paro signifas, ke TUN ne disponeblas kaj la norma reĝimo de OpenVPN ne povas ekfunkcii; rifuzo ĉe la lasta linio signifas, ke la kerna interfaco de WireGuard mankas. La kerna dokumentaro pri TUN/TAP priskribas la aparaton, kiun ekzercas la unua kontrolo. Neniu el la du fiaskoj ripariĝas per reinstalo de la VPN-pakaĵo.

Memoru, ke la enira vojo havas du posedantojn

La retaj reguloj de la provizanto kaj la fajroŝirmilo de la gasto estas apartaj sistemoj, kaj trafiko devas postvivi ambaŭ. Aŭskultanto ligita ĉe la gasto signifas nenion, se la sekureca grupo de la provizanto forĵetas la pordon, kaj malferma regulo de la provizanto faras nenion, se la gasto malakceptas la paketon. Kontrolu la aŭskultanton, poste la regulojn de la gasto, poste la panelon de la provizanto, en tiu ordo, kaj konfirmu kaj la protokolon kaj la pordnumeron. Salti unue al la panelo de la provizanto estas kiel homoj finas malfermi gamon, kiun ili ne bezonis.

UDP estas la kutima viktimo: multaj platformoj permesas TCP defaŭlte kaj traktas UDP-regulojn kiel apartan eron. Se la instanco sidas malantaŭ la NAT de la provizanto anstataŭ teni publikan adreson, porda plusendado ĉe la provizanta flanko fariĝas tria agordo por akordigi.

Planu la revenan vojon, ne nur la eliron

Plentunela servo bezonas ŝaltitan plusendadon, skemon de tradukado aŭ enkursigado por klienta trafiko, kaj revenan vojon, kiu atingas la klientaron. Malfermi aŭskultanton provizas neniun el ĉi tiuj. Tunelo, kiu establiĝas sed portas neniun utilan trafikon, kutime fiaskas ĉi tie, ne ĉe aŭtentikigo. Traktu sukcesan manpremon kiel komencon de la diagnozo, ne kiel ĝian finon.

Skribu la planon kiel tri konkretajn decidojn: kiun fontan gamon la klientoj ricevas, kiel ilia trafiko eliras al la interreto, kaj kiel respondoj trovas la vojon reen. Poste konfirmu, ke la kerno konsentas pri la plano antaŭ ol testi klienton, por ke silentan malkongruon oni ne prenu por klientoflanka fuŝo.

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

Decidu la IPv6-aferon eksplicite

IPv6 venas per pluraj mekanismoj, kiuj kondutas malsame por pordego: adreso sur la instanco, enkursigita prefikso, aŭ nenio. Nur enkursigita prefikso permesas al la servilo doni adresojn al klientoj laŭ la kutima maniero. Supozi, ke funkcianta IPv6-adreso sur la gastiganto implicas uzeblan klientan prefikson, estas eraro, kiu montriĝos poste kiel duone rompita konektebleco. Ĝi estas la speco de fuŝo, kiu postvivas ĉiun teston faritan nur per IPv4.

Se la provizanto enkursigas neniun prefikson, decidu, ĉu la tunelo estas nur IPv4 kaj ĉu oni diru tion al la klientoj. Dokumentita manko estas pli sekura ol parta agordo, kiu silente faligas IPv6-celojn en nigran truon por konektitaj uzantoj.

Pruvu ĝin per ekstera kliento

Loka serva stato priskribas unu procezon sur unu gastiganto. La utila testo estas rajtigita kliento en alia reto, kiu konektiĝas per la profilo, kiun vi intencas disdoni, poste atingas aplikaĵon kaj solvas nomon. Konektiĝu ankaŭ unufoje denove, ĉar tunelo, kiu funkcias nur ĉe la unua provo, malsukcesas la postulon, kiu plej gravas en praktiko.

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

Tenu la operaciajn bazojn apud la testo: spaco por ĝisdatigoj, limigitaj protokoloj, administra aliro, kiu ne dependas de la tunelo, reakira konzolo, kaj noto pri tio, kio okazas al klientaj profiloj, kiam la instanco estas rekonstruita kaj ĝia publika adreso ŝanĝiĝas. Se bezonata interfaco aŭ plusenda modelo simple ne disponeblas, neniu klientflanka ŝanĝo liveros ĝin, kaj la honesta sekva paŝo estas alia instanca tipo, ne pli da agordo.