WireGuard o OpenVPN: Alin ang I-self-Host?

Ang maikling sagot

Sa WireGuard kumpara sa OpenVPN, para sa isang taong nagpapatakbo ng VPN server sa sarili niyang VPS, hindi ito dikit na paghahambing: piliin ang WireGuard. Mas maliit ito, tumatakbo ito sa loob ng Linux kernel, kumokonekta ito sa loob ng maliit na bahagi ng isang segundo, at humigit-kumulang sampung linya lang ang working client config. May apat na aktuwal na gamit ang OpenVPN, at kung wala sa mga ito ang kailangan mo, hindi mo ito kailangan.

Ang apat na gamit na iyon ay ang paglabas mula sa network na TCP port 443 lang ang pinapayagan, pagkonekta sa kasalukuyang certificate authority, pag-authenticate sa mga pinangalanang user gamit ang password o second factor, at pag-bridge sa Layer 2. Ang lahat ng nasa ibaba ay ebidensiya para sa rekomendasyong ito, pati ang eksaktong punto kung kailan magsisimulang umiral ang bawat exception para sa iyo.

Bakit pinili ng mga self-hoster ang WireGuard

Sapat na maliit basahin ang codebase. Tinatayang 4,000 linya ng code ang implementasyon ng protocol ng WireGuard. Umaabot sa anim na digit ang OpenVPN kapag isinama ang library na OpenSSL na ginagamit nito sa bawat cryptographic operation. Mahalaga ang laki dahil bawat linya ay attack surface, at hindi mo o ng reviewer mo babasahin ang 100,000 linya. Maaari mong basahin ang 4,000.

Tumatakbo ito sa kernel. Kasama na ang WireGuard sa mainline Linux mula 5.6, kaya kasama na ito sa Ubuntu 24.04 at Debian 13 at walang kailangang i-compile. Ine-encrypt ang mga packet kung nasaan na ang mga ito, sa kernel space, nang hindi kinakailangang kopyahin sa userspace process at ibalik. Suriin muna ito bago ang iba:

sudo modprobe wireguard && echo ok

Sa KVM VPS, ipinapakita nito ang ok. Sa container virtualisation na gumagamit ng kernel ng host, gaya ng OpenVZ o LXC, nabibigo ito at ipinapakita ang Operation not supported, dahil hindi ka makakapag-load ng module sa kernel na hindi sa iyo.

Walang kailangang i-negotiate. May isang fixed cipher suite ang WireGuard: ChaCha20-Poly1305 para sa data, gamit ang mga Curve25519 key. Walang bersiyong maaaring i-downgrade at walang option na maaaring maling maitakda. Chine-check ng OpenVPN ang cipher at ang bersiyon ng TLS (transport layer security) sa bawat client. Nagbibigay ito ng flexibility, pero dito rin nangyayari ang misconfiguration. Ang server na iniwan na may data-ciphers AES-256-GCM:AES-128-CBC ay awtomatikong gagamit ng CBC cipher para sa client na walang inaalok na mas mahusay, at walang anuman sa log ang tutukoy dito bilang problema.

Hindi sumasagot ang port. Ibinabagsak ang WireGuard packet na hindi pumapasa sa message authentication check nang walang anumang reply, kaya ibinabalik ng nmap -sU -p 51820 ang open|filtered may nakikinig man o wala. Sa TCP mode ng OpenVPN, kinukumpleto muna ng server ang TCP handshake bago nito malamang hindi ka nito papapasukin. Sapat na iyon para mapatunayan sa scanner na may tumatakbo roon. Halos kasing tahimik ang OpenVPN over UDP kapag may tls-crypt, kaya argumento ito laban sa pagpapatakbo ng OpenVPN sa TCP, hindi laban sa OpenVPN mismo.

Libre ang roaming. Tinutukoy ang WireGuard peer batay sa public key nito, hindi sa address nito. Kapag lumipat ang laptop mo mula sa home network papunta sa mobile hotspot, nagpapadala ito ng isang handshake mula sa bagong address, at ina-update ng server ang endpoint na gagamitin nito sa pagtugon. Walang muling kumokonekta dahil wala namang permanenteng koneksiyon. May katulad na kakayahan ang OpenVPN gamit ang float, pero karaniwang winawasak at muling binubuo ng client ang buong TLS session. Dahil dito, kapansin-pansin ang paghinto kapag binuksan ang takip ng laptop sa OpenVPN, samantalang hindi ito nangyayari sa WireGuard.

Bilis sa 2026: lumiit ang agwat

Sa loob ng maraming taon, ang tapat na argumento tungkol sa bilis ay kinokopya ng OpenVPN ang bawat packet papunta sa userspace, ini-encrypt ito roon, at ibinabalik ang kopya, samantalang hindi kailanman umaalis sa kernel ang WireGuard. Hindi na ito ang buong larawan, kaya lipas na ang paghahambing na hindi ito isinasaalang-alang.

Inilabas ang OpenVPN 2.7 noong February 2026 na may suporta para sa upstream ovpn kernel module, na isinama sa Linux 6.16. Ito ang DCO (data channel offload): nananatili sa userspace ang control channel, habang inililipat sa kernel ang pangunahing data path. Ito ay halos kapareho ng matagal nang ginagawa ng WireGuard. Sa kernel at OpenVPN na sapat ang bagong bersyon para magamit ito, magkasing-uri ang throughput sa halip na magkaibang antas. Suriin kung ano talaga ang mayroon ka:

uname -r
openvpn --version | head -n 1
modinfo ovpn 2>/dev/null | head -n 3

Noong July 2026, ang stock Ubuntu 24.04 LTS ay may OpenVPN 2.6, hindi 2.7, at kailangan ng ovpn module ang 2.7. Sa release na iyon, makakakuha ka lamang ng offload sa pamamagitan ng mas lumang openvpn-dco-dkms package. Bumubuo ito ng out-of-tree module laban sa kasalukuyan mong kernel, kaya kailangan itong muling buuin sa bawat kernel upgrade. Isa itong bahaging kailangang pamahalaan na wala sa WireGuard.

Basahin ang mga limitasyon ng DCO bago mo ito ituring na dahilan para manatili. Layer 3 tunnels lamang ang sinusuportahan nito. AEAD ciphers lamang ang tinatanggap nito (authenticated encryption with associated data: AES-GCM o ChaCha20-Poly1305). Hindi nito sinusuportahan ang compression. Sa server, gumagana lamang ito sa topology subnet. Ang bawat isa sa mga limitasyong ito ay nag-aalis ng bahagi ng flexibility na dating pangunahing argumento para sa OpenVPN. Ang mabilis na OpenVPN ay OpenVPN na naka-configure na maging katulad ng WireGuard.

Huwag magtiwala sa anumang inilathalang throughput number, kabilang ang nasa pahinang ito. Sa isang VPS, karaniwang ang CPU allowance o network allowance ang nagtatakda ng limitasyon, hindi ang protocol. Sukatin ang sarili mong performance gamit ang iperf3 na tumatakbo sa tunnel, pagkatapos ay ulitin ito sa labas ng tunnel, at ihambing ang dalawang resulta.

Kung kailan kapaki-pakinabang pa rin ang OpenVPN

Kailangan mong makalabas sa TCP port 443. UDP-only ang WireGuard, ayon sa disenyo, at walang darating na TCP mode. Papayagan ng hotel network o corporate proxy na tumatanggap lamang ng TCP 443 ang OpenVPN kapag naka-configure ito gamit ang proto tcp-server at port 443, dahil mukhang karaniwang TLS session ang traffic na iyon. Kailangan ng WireGuard ng wrapper tulad ng wstunnel o udp2raw para makatawid sa parehong network. Nangangahulugan ito ng isa pang prosesong patatakbuhin at papanatilihing updated sa mga patch. Tandaan ang conflict: kung may web server nang gumagamit ng TCP 443 sa IP address na iyon, kailangang ilipat ang isa sa dalawa.

May pinapatakbo ka nang certificate authority. Nagpapatotoo ang OpenVPN gamit ang X.509 certificates, kaya direktang maisasama ito sa PKI (public key infrastructure) na pinapatakbo mo na. Kusang nag-e-expire ang mga certificate. Para i-revoke ang isa, idagdag ito sa certificate revocation list na binabasa ng server sa pamamagitan ng crl-verify. Walang certificate, expiry, o revocation list ang WireGuard. Para alisin ang isang peer, kailangan mong i-edit ang server config at i-reload ito. Ayos ito para sa ten peers. Sa four hundred peers na may audit requirement, mahalaga ang certificate model.

Kailangan mo ng mga pinangalanang user, hindi keys lamang. Maaaring ipasa ng OpenVPN ang authentication sa external system gamit ang auth-user-pass-verify o isang plugin tulad ng openvpn-plugin-auth-pam.so. Ganito nagdaragdag ng LDAP o one-time-password second factor. Walang konsepto ng user ang WireGuard. Ang key ay nasa config o wala roon. Kung ang requirement mo ay "Dapat maglagay si Sara ng code mula sa phone niya", hindi ito kayang ipatupad ng WireGuard nang mag-isa.

Kailangan mo ng Layer 2, o ng client para sa lumang system. Binabridge ng OpenVPN gamit ang dev tap ang mga Ethernet frame. Mahalaga ito para sa mga broadcast protocol at lumang LAN game. Layer 3 lamang ang WireGuard at mananatili itong ganoon. May clients din ang OpenVPN sa hardware at operating system na hindi kailanman magkakaroon ng WireGuard app. Lalong nababawasan ang kahalagahan ng dalawang dahilang ito. Hindi compatible ang dev tap sa DCO, kaya mabagal na path ang gagamitin mo kapag pinili mo ang bridge.

Ang aktuwal na gastos ng dalawang setup

Ang isang WireGuard identity ay isang command. Mahalaga ang parentheses dahil itinatakda ng mga ito ang file mode bago malikha ang key:

(umask 077; wg genkey > private.key)
wg pubkey < private.key > public.key

Ang katumbas sa OpenVPN ay isang certificate authority na pagmamay-ari mo habang ginagamit ang VPN:

sudo apt install -y easy-rsa
make-cadir ~/openvpn-ca
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca
./easyrsa gen-req server nopass
./easyrsa sign-req server server

Walang hindi patas sa alinmang listahan. Nagbibigay ang CA ng expiry at revocation. Kapalit nito, kailangan mong protektahan ang private key sa loob ng maraming taon, tandaan ang renewal, at buuin muli ang setup kapag nawala ito. Kung hindi mo ginagamit ang mga benepisyong ibinibigay nito, wala kang napapala sa gastos. Makikita ang buong proseso ng WireGuard, kabilang ang forwarding, NAT (network address translation), at mga handshake failure na maaaring kumain ng isang hapon, sa gabay sa pagho-host ng sarili mong WireGuard VPN sa iyong VPS.

Ang hinihingi ng bawat isa sa iyong firewall

Kailangan ng WireGuard ng eksaktong isang inbound rule para sa UDP sa port na nasa ListenPort:

sudo ufw allow 51820/udp
sudo ufw status verbose

Bilang default, kailangan ng OpenVPN ng UDP 1194, o TCP 443 kung iyon ang pinili mong configuration. Kailangan din ng dalawa na i-enable ang IP forwarding at magtakda ng source NAT rule, dahil nagtatapon ang Linux box ng mga packet na hindi nakatalaga rito. Magkapareho ang bahaging ito para sa dalawang protocol, at dito nagmumula ang karamihan ng mga ulat na “nakakonekta ang tunnel pero walang internet.” Kung bago sa iyo ang ufw, magsimula sa mga pangunahing kaalaman sa ufw firewall sa isang VPS, at tandaan na karamihan ng provider ay nagpapatakbo ng pangalawang network firewall sa control panel nila: walang epekto ang rule na idinagdag mo sa server kung hindi naman nakakarating ang packet sa server. Ang pag-unawa sa kung ano ang port at kung paano nakikinig dito ang Linux ay nagpapabilis sa dalawang pagsusuring ito.

Paano pumili, sa isang talata

Gamitin ang WireGuard maliban kung matukoy mo ang partikular na bagay na hindi nito kayang gawin para sa iyo. Kung kailangan mo ng TCP 443 upang makalusot sa restrictive na network, gamitin ang OpenVPN doon, at isaalang-alang ang paggamit ng pareho: magkaiba ang port na ginagamit ng mga ito at maaari silang magkasamang tumakbo sa isang server nang walang conflict. Kung kailangan mo ng mga account para sa bawat user o ng second factor, huwag mong piliting gawin iyon sa WireGuard. Sa halip, maglagay ng identity layer sa ibabaw nito. Ang sariling-host na Headscale control server ay gumagamit ng WireGuard sa ilalim at nagdaragdag ng account model, key distribution, at device approval na kailangan mong pamahalaan kapag plain WireGuard ang ginagamit.

Paglipat mula sa OpenVPN nang walang outage

Walang conversion. Ang PKI ng OpenVPN ay hindi nagiging mga key ng WireGuard, dahil walang certificate ang WireGuard na maaaring i-convert. Bawat client ay bibigyan ng bagong key pair na gagawin sa parehong paraan ng key pair ng server.

Mag-migrate nang magkatabi sa halip na basta magpalit. Ang WireGuard sa UDP 51820 at ang OpenVPN sa 1194 ay maaaring sabay na tumakbo sa iisang box. Kaya i-start ang wg0, kumpirmahin ito gamit ang sudo wg show na naglilista ng isang kamakailang latest handshake, at pagkatapos ay ilipat ang mga client nang paisa-isa. Kapag hindi na nagbabago ang listahan ng mga OpenVPN peer, ihinto ang service gamit ang sudo systemctl disable --now openvpn-server@server. Panatilihin ang mga CA file hanggang makasiguro ka, dahil hindi posibleng buuin muli ang isang na-revoke na client gamit ang CA na tinanggal mo na.

May isang bagay na talagang hindi naililipat: ang mga account na gumagamit ng username at password, pati ang talaan ng mga revocation na nauugnay sa mga ito. Magpasya kung saan ito itatabi bago mo isara ang lumang server, hindi pagkatapos.

FAQ

Mas mabilis ba ang WireGuard kaysa sa OpenVPN?

Oo, sa isang karaniwang Ubuntu 24.04 server, at malaki ang lamang nito, dahil nag-e-encrypt ang WireGuard sa kernel samantalang ipinapadaan ng OpenVPN 2.6 ang bawat packet sa isang userspace process. Sa OpenVPN 2.7 at sa ovpn kernel module mula sa Linux 6.16, nasa kernel na rin ang data path kaya magkapantay na ang antas ng dalawa. Sukatin ang sarili mong resulta gamit ang iperf3 sa tunnel sa halip na umasa sa numerong nasa isang blog, dahil sa VPS, karaniwang CPU o bandwidth allowance ang limitasyon.

Maaari bang patakbuhin ang WireGuard sa TCP port 443?

Hindi nang mag-isa. UDP lamang ang WireGuard ayon sa disenyo, at walang planong magdagdag ng TCP mode. Para makadaan sa network na TCP 443 lamang ang pinapayagan, ibalot ito sa tunnel gaya ng wstunnel o udp2raw. Nagdaragdag ito ng process na kailangang patakbuhin at i-patch sa magkabilang dulo. Kung karaniwan mong ginagamit ang ganitong environment, mas simpleng sagot ang OpenVPN na may proto tcp-server at port 443.

Hindi na ba secure ang OpenVPN?

Hindi. Ang kasalukuyang OpenVPN na may AEAD cipher gaya ng AES-256-GCM at naka-enable ang tls-crypt ay isang maaasahang VPN. Iba ang batayan para piliin ang WireGuard: mas marami ang code at mas marami ang option ng OpenVPN, kaya mas marami itong paraan para maling ma-configure ng isang pagod na administrator. Kapag mas kaunti ang pagpipilian, mas kaunti rin ang posibleng maling configuration.

Alin ang dapat kong piliin para sa personal na VPN sa isang VPS?

WireGuard. Isang key pair bawat device, isang config file na humigit-kumulang sampung linya, isang UDP port na kailangang buksan, at isang handshake na natatapos bago mo mapansing nagsimula ito. Piliin lamang ang OpenVPN kung regular kang kumokonekta mula sa mga network na nagba-block ng UDP, o kung kailangan mong gumamit ng certificate authority o user directory na mayroon na.