Isang pribadong tunnel na may malinaw na layunin.

Tukuyin ang ruta

Magpasya kung ang tunnel ay nagdadala lamang ng pribadong trapiko ng serbisyo o lahat ng trapiko sa internet. I-configure nang sinasadya ang mga pinapayagang ruta at isaalang-alang ang parehong IPv4 at IPv6. Magkaiba ang mga pagsasaalang-alang sa leak at maabot ng split-tunnel at full-tunnel setup.

Isang key bawat device

Bumuo ng private key sa device kung praktikal at huwag kailanman i-publish ang mga ito. Gumamit ng hiwalay na peer identity upang ma-revoke ang nawalang device nang hindi pinapalitan ang bawat client. Itago ang server configuration na may protektadong permissions.

I-configure ang forwarding at DNS

Sadyang itakda ang forwarding at firewall rules. Suriin ang name resolution, MTU at ang return path. Subukan ang epektibong pampublikong address at pag-uugali ng DNS mula sa client sa halip na ipagpalagay na ang matagumpay na handshake ay nangangahulugang lahat ng trapiko ay gumagamit ng nilalayong ruta.

Unawain ang pagbabago ng tiwala

Ang self-hosted VPN ay makakaprotekta ng trapiko sa lokal na network, ngunit nakikita pa rin ng VPS at upstream ang metadata at anumang hindi naka-encrypt na trapiko. Hindi nito ginagawang anonymous ang isang browser session o binabalewala ang mga patakaran ng mga serbisyong ina-access mo.

Gumamit ng tahasang listener at siyasatin ang handshake

Ang UDP 51820 ay karaniwang pagpipilian sa configuration ng WireGuard, hindi mandatory o garantisadong patakaran ng host. Buksan lamang ang napiling UDP port at panatilihing hiwalay na nakakulong ang administrasyon. Maaaring iulat ng command na wg show ang impormasyon ng peer handshake at transfer nang hindi kailangang ilathala ang mga private key.

• I-verify ang kamakailang handshake
• Subukan ang inilaan na pribadong serbisyo
• Subukan ang internet at DNS na ruta lamang kung buong tunnel ang balak

wg show

Opisyal na dokumentasyon: Mabilisang pagsisimula sa WireGuard

Gamitin ang keepalives lamang kapag kailangan ito ng network

Ang peer sa likod ng NAT ay maaaring mangailangan ng pana-panahong keepalive traffic upang mapanatili ang mapping para sa inbound packets. Ang angkop na setting ay depende sa network. Panatilihing sinadya ang configuration; huwag kopyahin ang buong-tunnel na recipe kung ang layunin lamang ay access sa isang pribadong application.

Pumili ng split tunnelling o full-tunnel na disenyo

Magsimula sa aktwal na layunin. Ang split tunnel ay maaaring magdala lamang ng pribadong subnet o serbisyong administratibo; ang full tunnel ay nangangailangan din ng internet forwarding, mga patakaran sa egress at planong DNS. Pumili ng mga address ng tunnel na hindi nag-o-overlap at magpasya kung paano hahawakan ang IPv6. Ang UDP51820 ay karaniwang port, hindi kinakailangan. Kumpirmahin ang patakaran ng napiling host at panatilihing available ang console/administrator access habang binabago ang mga ruta o patakaran ng firewall.

• Bigyan ang bawat device ng natatanging key pair at makitid na peer identity.
• Panatilihin ang mga pribadong key sa kanilang inilaan na device at ilayo sa mga pampublikong file o pagbabahagi ng QR.
• Ituring ang mga pampublikong endpoint at client roaming bilang bahagi ng disenyo ng network.

Opisyal na dokumentasyon: Mabilisang pagsisimula sa WireGuard

Mag-set up ng maliit na tunnel bago magdagdag ng internet routing

Sundin ang sinusuportahang pag-install ng OS at bumuo ng mga key na may mahigpit na file permission. I-configure ang server interface, isang peer at ang napiling UDP listener. Karaniwang dapat may sariling tunnel address sa AllowedIPs ang isang server-side peer sa halip na mag-overlap na catch-all na itinalaga sa maraming client. Magsimula sa access sa tunnel address, pagkatapos ay idagdag ang mga aprubadong forwarding at destination route. Ang matagumpay na handshake ay nagpapatunay ng pakikipag-ugnayan sa peer, hindi na tama ang DNS o internet egress.

# Inspection examples; these do not reveal a private key:
wg show
ip address show dev wg0
ip route get 10.44.0.1

Opisyal na dokumentasyon: Configuration ng WireGuard interface at peer

Subukan ang inaasahang path at isang ipinagbabawal na path

Mula sa client, i-verify ang kamakailang handshake at isang pinapayagang pribadong serbisyo. Subukan ang isang destinasyong dapat tanggihan. Kung gumagamit ng full tunnel, suriin ang epektibong pampublikong ruta, DNS resolver at pag-uugali ng IPv6 mula sa client na iyon; dapat panatilihin ng split-tunnel traffic ang inilaan na lokal na landas. Ulitin pagkatapos ng pagbabago sa network ng client. Gumamit ng NAT keepalive lamang kapag kailangan ito ng network ng peer, at panatilihing pare-pareho ang interval sa dokumentadong disenyo.

• Walang handshake: siyasatin ang endpoint na DNS, ang maabot ng UDP, mga key at peer mapping.
• May Handshake ngunit walang serbisyo: suriin ang AllowedIPs, firewall, forwarding at ang return route.
• May mga site na nag-stall: imbestigahan ang path MTU bago maglapat ng random na permanenteng halaga.

Gawing paulit-ulit ang revocation at reboot behaviour

Alisin ang peer key ng nawalang device at kumpirmahing hindi na ito makakapagtatag ng nilalayong pag-access. Panatilihin ang mga naka-encrypt na backup ng configuration at isang imbentaryo kung aling public key ang nabibilang sa aling device. Subukan kung bumabalik ang interface at mga kinakailangang routing rule pagkatapos ng normal na reboot. Inililipat ng VPN ang tiwala patungo sa VPS at sa upstream nito; hindi nito inaalis ang mga identifier ng application, account cookies o ang pangangailangan ng HTTPS patungo sa huling destinasyon.

Opisyal na dokumentasyon: Manwal ng WireGuard wg-quick