Ano ang Dapat Payagan ng VPS Bago Ito Makapag-host ng Iyong VPN

Nagbo-boot ang instance, nagtatagumpay ang mga pag-install ng package, at nag-uulat pa nga ang serbisyo ng tumatakbong estado, ngunit walang kumokonekta. Karaniwan ang pattern na ito sa mga virtual private server, dahil ang guest na komportableng nakakaabot sa internet ay maaari pa ring hindi makagawa ng interface na gusto ng iyong protocol. Limang pagsusuri ang naghihiwalay sa host na makapaglilingkod ng tunnel mula sa isa na mukha lang handa, at ang unang pagsusuring nabigo ay karaniwang nagpapaliwanag ng lahat pagkatapos nito. Bawat isa ay mura patakbuhin at nagtatapos sa desisyon, hindi sa tala.

Kumpirmahin ang interface na kailangan ng protocol

OpenVPN sa TUN ay nangangailangan ng character device at ng kernel module sa likod nito; ang WireGuard ay nangangailangan ng sarili nitong suporta sa kernel o implementasyon sa user space na may tugmang inaasahan. Maaaring magbahagi ang mga pinamamahalaang container ng host kernel na hindi kailanman inilalantad ang device, at ang ilang platform ay ganap na nagbabawal sa paggawa ng tunnel interface, anuman ang naka-install.

Subukan ang kakayahan sa halip na magbasa ng support page, dahil mas mabilis magbago ang mga marketing label kaysa sa pinagbabatayang limitasyon. Ang listahan ng feature na isinulat para sa isang plan ay maaaring hindi naglalarawan sa kernel kung saan talagang tumatakbo ang guest. Dalawang maiikling command ang sumasagot sa tanong para sa karaniwang ginagamit na protocol, at parehong naglilinis pagkatapos. Ang mga command sa ibaba ay hindi gumagawa ng anumang permanente at agad na tinatanggal.

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

Ang pagtanggi sa unang pares ay nangangahulugang hindi available ang TUN at hindi makapagsimula ang default mode ng OpenVPN; ang pagtanggi sa huling linya ay nangangahulugang kulang ang kernel interface ng WireGuard. Ang dokumentasyon ng kernel tungkol sa TUN/TAP ay naglalarawan sa device na sinasanay ng unang pagsusuri. Wala sa dalawang kabiguan ang naaayos sa pamamagitan ng muling pag-install ng VPN package.

Tandaan na ang papasok na landas ay may dalawang may-ari

Ang mga patakaran ng network ng provider at ang firewall ng guest ay magkahiwalay na sistema, at ang trapiko ay dapat makalampas sa pareho. Ang listener na nakatali sa guest ay walang ibig sabihin kung itinatapon ng security group ng provider ang port, at ang bukas na patakaran ng provider ay walang ginagawa kung tinatanggihan ng guest ang packet. I-verify ang listener, pagkatapos ang mga patakaran ng guest, pagkatapos ang panel ng provider, sa ganoong pagkakasunod-sunod, at kumpirmahin ang protocol pati na ang numero ng port. Ang paglukso agad sa panel ng provider ang paraan kung paano nagbubukas ang mga tao ng saklaw na hindi nila kailangan.

Ang UDP ang karaniwang biktima: maraming platform ang nagpapahintulot ng TCP bilang default at itinuturing ang mga patakaran ng UDP na hiwalay na entry. Kung ang instance ay nasa likod ng NAT ng provider sa halip na may pampublikong address, ang port forwarding sa panig ng provider ay nagiging pangatlong configuration na dapat isaayos.

Planuhin ang pabalik na landas, hindi lang ang labasan

Ang full-tunnel na serbisyo ay nangangailangan ng naka-enable na forwarding, isang scheme ng pagsasalin o routing para sa trapiko ng kliyente at pabalik na landas na umaabot sa pool ng kliyente. Ang pagbubukas ng listener ay wala sa mga ito. Ang tunnel na nagtatatag ngunit walang dalang kapaki-pakinabang na trapiko ay karaniwang nabigo dito, hindi sa authentication. Ituring ang matagumpay na handshake bilang simula ng diagnosis, hindi ang wakas nito.

Isulat ang plano bilang tatlong konkretong desisyon: kung anong source range ang natatanggap ng mga kliyente, paano lumalabas ang kanilang trapiko patungong internet, at paano nahahanap ng mga sagot ang pabalik na landas. Pagkatapos ay kumpirmahin na sumasang-ayon ang kernel sa plano bago subukan ang isang kliyente, para hindi mapagkamalang depekto sa panig ng kliyente ang tahimik na hindi pagkakatugma.

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

Desisyunan ang usapin ng IPv6 nang tahasan

Dumadating ang IPv6 sa pamamagitan ng ilang mekanismo na iba ang pag-uugali para sa isang gateway: isang address sa instance, isang niruruta na prefix, o wala talaga. Tanging niruruta na prefix ang nagpapahintulot sa server na magbigay ng address sa mga kliyente sa karaniwang paraan. Ang pagpapalagay na ang gumaganang IPv6 address sa host ay nangangahulugan ng magagamit na prefix ng kliyente ay isang pagkakamaling lumalabas mamaya bilang kalahating sirang koneksyon. Ito ang uri ng depektong nakakalampas sa bawat pagsubok na ginagawa gamit lamang ang IPv4.

Kung walang niruruta na prefix ang provider, desisyunan kung IPv4 lamang ang tunnel at kung dapat sabihan ang mga kliyente. Ang dokumentadong kawalan ay mas ligtas kaysa sa bahagyang configuration na tahimik na nagtatapon ng mga destinasyong IPv6 sa isang itim na butas para sa mga konektadong user.

Patunayan ito mula sa panlabas na kliyente

Ang lokal na estado ng serbisyo ay naglalarawan ng isang proseso sa isang host. Ang kapaki-pakinabang na pagsubok ay isang awtorisadong kliyente sa ibang network, na kumokonekta gamit ang profile na balak mong ipamahagi, pagkatapos ay umaabot sa isang application at nagreresolba ng pangalan. Kumonekta muli nang isang beses, dahil ang tunnel na gumagana lamang sa unang pagtatangka ay hindi tumutupad sa pangangailangang pinakamahalaga sa praktika.

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

Panatilihin ang mga operasyonal na batayan sa tabi ng pagsubok: espasyo para sa mga update, limitadong log, administratibong access na hindi umaasa sa tunnel, isang recovery console, at tala kung ano ang nangyayari sa mga profile ng kliyente kapag muling itinayo ang instance at nagbago ang pampublikong address nito. Kung ang kinakailangang interface o modelo ng forwarding ay talagang wala, walang pagbabago sa panig ng kliyente ang magbibigay nito, at ang tapat na susunod na hakbang ay ibang uri ng instance, hindi mas maraming configuration.