Panduan referensi API untuk WireGuard termasuk Penyiapan, Konfigurasi, dan Penggunaan, beserta contohnya.
Semua kredit diberikan kepada proyek WireGuard, zx2c4 dan kontributor sumber terbuka untuk perangkat lunak asli,
ini adalah upaya tidak resmi saya untuk menyediakan dokumentasi, referensi API, dan contoh yang lebih komprehensif.
Sumber untuk dokumen ini, kode contoh, dan pelacak masalah: https://github.com/pirate/wireguard-docs Versi halaman HTML yang lebih bagus: https://docs.sweeting.me/s/wireguard
WireGuard adalah solusi VPN sumber terbuka yang ditulis dalam C oleh Jason Donenfeld dan lainnya, yang bertujuan untuk memperbaiki banyak masalah yang mengganggu penawaran VPN server-ke-server modern lainnya seperti IPSec/IKEv2, OpenVPN, atau L2TP. Ia memiliki beberapa kesamaan dengan penawaran VPN modern lainnya seperti Tinc dan MeshBird, yaitu cipher suite yang bagus dan konfigurasi minimal. Pada 01-2020, kernel ini telah digabungkan ke dalam kernel Linux versi 5.6, yang berarti kernel tersebut akan disertakan dengan sebagian besar sistem Linux secara langsung.
Tautan Resmi
wg
, wg-quick
Tujuan WireGuard
Lihat https://github.com/pirate/wireguard-docs untuk contoh kode dan sumber dokumentasi.
Baik tinggal di balik Tembok Besar Tiongkok atau hanya mencoba membentuk jaringan antar server Anda, WireGuard adalah pilihan bagus dan berfungsi sebagai "blok lego" untuk membangun jaringan (sama seperti ZFS adalah blok lego untuk membangun sistem file ).
Hal-hal yang tidak dilakukan WireGuard:
Namun Anda dapat menulis solusi Anda sendiri untuk masalah ini menggunakan WireGuard (seperti Tailscale atau AltheaNet).
Ini adalah nama host demo, nama domain, alamat IP, dan rentang yang digunakan dalam dokumentasi dan contoh konfigurasi. Gantikan dengan nilai pilihan Anda saat melakukan pengaturan sendiri.
example-vpn.dev
dapat diganti dengan domain apa pun yang dapat diakses publik yang Anda kendalikanpublic-server1
, public-server2
, home-server
, laptop
, phone
dapat diubah menjadi nama host perangkat Anda192.0.2.1/24
, 192.0.2.3
, 192.0.2.3/32
, 2001:DB8::/64
dapat diganti dengan subnet dan alamat pilihan Anda (misalnya 192.168.5.1/24
)Di mana pun Anda melihat string di bawah, string tersebut hanya digunakan sebagai nilai placeholder untuk mengilustrasikan contoh dan tidak memiliki arti khusus.
Pastikan untuk mengubah alamat IP di konfigurasi Anda! Blok yang digunakan dalam dokumen ini dicadangkan untuk tujuan contoh oleh IETF dan tidak boleh digunakan dalam pengaturan jaringan sebenarnya.
192.0.2.0/24
(TEST-NET-1) Rentang contoh IPv4 RFC57372001:DB8::/32
rentang contoh IPv6 RFC3849 Anda dapat menggunakan rentang pribadi apa pun yang Anda inginkan untuk pengaturan Anda sendiri, misalnya 10.0.44.0/24
, pastikan saja rentang tersebut tidak bertentangan dengan rentang subnet LAN mana pun yang digunakan rekan Anda.
Host yang terhubung ke VPN dan mendaftarkan alamat subnet VPN seperti 192.0.2.3
untuk dirinya sendiri. Secara opsional, ia juga dapat merutekan lalu lintas ke lebih dari alamatnya sendiri dengan menentukan rentang subnet dalam notasi CIDR yang dipisahkan koma.
Rekan/node yang dapat dijangkau secara publik dan berfungsi sebagai pengganti untuk meneruskan lalu lintas ke rekan VPN lain di belakang NAT. Server bouncing bukanlah jenis server khusus, ini adalah peer normal sama seperti server lainnya, satu-satunya perbedaan adalah server tersebut memiliki IP publik dan penerusan IP tingkat kernel diaktifkan yang memungkinkannya memantulkan lalu lintas kembali ke VPN kepada klien lain.
Lihat selengkapnya: https://tailscale.com/blog/how-nat-traversal-works/ (Tailscale menggunakan Wireguard di bawah tenda)
Sekelompok IP yang terpisah dari internet publik, misalnya 192.0.2.1-255 atau 192.168.1.1/24. Umumnya di belakang NAT disediakan oleh router, misalnya di LAN internet kantor atau jaringan Wi-Fi rumah.
Sebuah cara untuk mendefinisikan subnet dan ukurannya dengan "mask", mask yang lebih kecil = lebih banyak bit alamat yang dapat digunakan oleh subnet & lebih banyak IP dalam jangkauannya. Yang paling umum:
192.0.2.1/32
(satu alamat IP, 192.0.2.1
) netmask = 255.255.255.255
192.0.2.1/24
(255 IP dari 192.0.2.0
- 192.0.2.255
) netmask = 255.255.255.0
192.0.2.1/16
(65.536 IP dari 192.0.0.0
- 192.0.255.255
) netmask = 255.255.0.0
192.0.2.1/8
(16.777.216 IP dari 192.0.0.0
- 192.255.255.255
) netmask = 255.0.0.0
0.0.0.1/0
(4.294.967.296 IP dari 0.0.0.0
- 255.255.255.255
) netmask = 0.0.0.0
2001:DB8::/64
https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Bagi orang yang baru memulai, 192.0.2.1/32
mungkin tampak aneh dan membingungkan untuk merujuk ke satu IP. Desain ini bagus karena memungkinkan rekan untuk mengekspos beberapa IP jika diperlukan tanpa memerlukan banyak notasi. Ketahuilah bahwa di mana pun Anda melihat sesuatu seperti 192.0.2.3/32
, itu sebenarnya berarti 192.0.2.3
.
Sebuah subnet dengan IP pribadi yang disediakan oleh router yang berdiri di depannya melakukan Penerjemahan Alamat Jaringan, masing-masing node tidak dapat diakses publik dari internet, sebagai gantinya router melacak koneksi keluar dan meneruskan respons ke IP internal yang benar (misalnya jaringan kantor standar , jaringan Wi-Fi rumah, jaringan Wi-Fi publik gratis, dll)
Alamat:port yang dapat diakses publik untuk sebuah node, misalnya 123.124.125.126:1234
atau some.domain.tld:1234
(harus dapat diakses melalui internet publik, umumnya tidak boleh berupa IP pribadi seperti 192.0.2.1
atau 192.168.1.1
kecuali itu dapat diakses langsung menggunakan alamat itu oleh rekan-rekan lain di subnet yang sama).
Kunci pribadi WireGuard untuk satu node, dihasilkan dengan: wg genkey > example.key
(tidak pernah meninggalkan node tempat kunci tersebut dibuat)
Kunci publik WireGuard untuk satu node, dihasilkan dengan: wg pubkey < example.key > example.key.pub
(dibagikan dengan rekan lain)
Server Nama Domain, digunakan untuk menyelesaikan nama host menjadi IP untuk klien VPN, alih-alih membiarkan permintaan DNS bocor ke luar VPN dan mengungkapkan lalu lintas. Kebocoran dapat diuji dengan http://dnsleak.com.
Relai publik hanyalah rekan VPN biasa yang dapat bertindak sebagai server relai perantara antara klien VPN mana pun di belakang NAT, mereka dapat meneruskan lalu lintas subnet VPN apa pun yang mereka terima ke rekan yang benar di tingkat sistem (WireGuard tidak peduli bagaimana hal ini terjadi , ini ditangani oleh kernel net.ipv4.ip_forward = 1
dan aturan perutean iptables).
Jika semua peer dapat diakses secara publik, Anda tidak perlu khawatir tentang perlakuan khusus untuk menjadikan salah satu dari mereka sebagai server relay, itu hanya diperlukan jika Anda memiliki rekan yang terhubung dari belakang NAT.
Setiap klien hanya perlu menentukan server/rekan yang dapat diakses publik dalam konfigurasinya, lalu lintas apa pun yang terikat ke rekan lain di belakang NAT akan masuk ke subnet VPN penampung semua (misalnya 192.0.2.1/24
) di rute Relai Publik AllowedIPs
dan akan diteruskan sesuai dengan itu setelah mencapai server relay.
Singkatnya: hanya koneksi langsung antar klien yang harus dikonfigurasi, koneksi apa pun yang perlu dipantulkan tidak boleh didefinisikan sebagai rekan, karena koneksi tersebut harus menuju ke server pentalan terlebih dahulu dan dirutekan dari sana kembali ke vpn ke klien yang benar.
Topologi yang lebih kompleks pasti dapat dicapai, namun berikut adalah metode perutean dasar yang digunakan dalam pengaturan WireGuard pada umumnya:
Endpoint
yang dikodekan secara hardcode sehingga WireGuard dapat terhubung langsung ke port terbuka dan merutekan paket UDP tanpa lompatan perantara.public-server2
), tentukan node yang dapat diakses publik dengan Endpoint
yang di-hardcode dan node dengan NAT tanpa. Koneksi akan dibuka dari klien NAT -> klien publik, lalu lalu lintas akan dirutekan langsung di antara mereka di kedua arah selama koneksi tetap hidup dengan keluar ping PersistentKeepalive
dari klien yang diberi NAT.public-server1
, dan lalu lintas akan diteruskan melalui server pentalan perantara selama koneksi masih ada. tetap hidup. Rute yang lebih spesifik (juga biasanya lebih langsung) yang disediakan oleh rekan lain akan diutamakan jika tersedia, jika tidak, lalu lintas akan kembali ke rute yang paling tidak spesifik dan menggunakan catchall 192.0.2.1/24
untuk meneruskan lalu lintas ke server pentalan, di mana ia akan masuk gilirannya dirutekan oleh tabel perutean sistem server relai ( net.ipv4.ip_forward = 1
) kembalikan VPN ke rekan tertentu yang menerima rute untuk lalu lintas tersebut. WireGuard tidak secara otomatis menemukan rute tercepat atau mencoba membentuk koneksi langsung antar peer jika belum ditentukan, WireGuard hanya berpindah dari rute paling spesifik di [Peers]
ke yang paling tidak spesifik.
Anda dapat mengetahui metode perutean mana yang digunakan WireGuard untuk alamat tertentu dengan mengukur waktu ping untuk mengetahui panjang unik setiap hop, dan dengan memeriksa keluaran dari:
wg show wg0
WireGuard menggunakan paket UDP terenkripsi untuk semua lalu lintas, namun tidak memberikan jaminan seputar pengiriman atau pemesanan paket, karena hal tersebut ditangani oleh koneksi TCP dalam terowongan terenkripsi.
Bacaan lebih lanjut:
WireGuard mengklaim kinerja lebih cepat dibandingkan kebanyakan solusi VPN pesaing lainnya, meskipun angka pastinya terkadang diperdebatkan dan mungkin bergantung pada apakah akselerasi tingkat perangkat keras tersedia untuk sandi kriptografi tertentu.
Peningkatan kinerja WireGuard dicapai dengan menangani perutean di tingkat kernel, dan dengan menggunakan rangkaian sandi modern yang berjalan di semua inti untuk mengenkripsi lalu lintas. WireGuard juga memperoleh keuntungan signifikan dengan menggunakan UDP tanpa jaminan pengiriman/pemesanan (dibandingkan dengan VPN yang dijalankan melalui TCP atau menerapkan mekanisme pengiriman jaminannya sendiri).
Bacaan lebih lanjut:
WireGuard menggunakan protokol dan primitif berikut untuk mengamankan lalu lintas:
Kriptografi WireGuard pada dasarnya adalah contoh kerangka kerja Noise Trevor Perrin. Ini modern dan, sekali lagi, sederhana. Setiap opsi VPN lainnya adalah negosiasi dan jabat tangan yang berantakan serta mesin negara yang rumit. WireGuard seperti Signal/Axolotl VPN, hanya saja lebih sederhana dan mudah untuk dipikirkan (dalam hal ini secara kriptografis) dibandingkan protokol perpesanan double ratchet. Ini pada dasarnya adalah qmail dari perangkat lunak VPN. Dan itu ~4000 baris kode. Jumlahnya jauh lebih kecil dibandingkan kompetitornya.
https://news.ycombinator.com/item?id=14599834
Bacaan lebih lanjut:
Otentikasi di kedua arah dicapai dengan pasangan kunci publik/pribadi sederhana untuk setiap rekan. Setiap rekan menghasilkan kunci ini selama fase penyiapan, dan hanya membagikan kunci publik dengan rekan lainnya.
Tidak ada sertifikat atau kunci yang dibagikan sebelumnya yang diperlukan selain kunci publik/pribadi untuk setiap node.
Pembuatan, distribusi, dan pencabutan kunci dapat ditangani dalam penerapan yang lebih besar menggunakan layanan terpisah seperti Ansible atau Kubernetes Secrets.
Beberapa layanan yang membantu distribusi dan penerapan kunci:
Anda juga dapat membaca kunci dari file atau melalui perintah jika Anda tidak ingin melakukan hardcode di wg0.conf
, ini membuat pengelolaan kunci melalui layanan pihak ketiga menjadi lebih mudah:
[Interface]
...
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privkey)
Secara teknis, beberapa server dapat berbagi kunci pribadi yang sama selama klien tidak terhubung ke dua server dengan kunci yang sama secara bersamaan. Contoh skenario di mana pengaturan ini masuk akal adalah jika Anda menggunakan DNS round-robin untuk menyeimbangkan beban koneksi antara dua server yang berpura-pura menjadi satu server. Namun sering kali, setiap rekan harus memiliki pasangan kunci publik/pribadinya sendiri sehingga rekan tidak dapat membaca lalu lintas satu sama lain dan dapat dicabut satu per satu.
Ikhtisar proses umum:
apt install wireguard
atau pkg/brew install wireguard-tools
di setiap nodewg genkey
+ wg pubkey
wg0.conf
di server relay utama[Interface]
Pastikan untuk menentukan rentang CIDR untuk seluruh subnet VPN saat menentukan alamat yang menerima rute server untuk Address = 192.0.2.1/24
[Peer]
Buat bagian peer untuk setiap klien yang bergabung dengan VPN, menggunakan kunci publik jarak jauh yang sesuaiwg0.conf
di setiap node klien[Interface]
Pastikan untuk menentukan hanya satu IP untuk rekan klien yang tidak menyampaikan lalu lintas Address = 192.0.2.3/32
.[Peer]
Buat bagian rekan untuk setiap rekan publik yang tidak berada di belakang NAT, pastikan untuk menentukan rentang CIDR untuk seluruh subnet VPN saat menentukan rekan jarak jauh yang bertindak sebagai server pentalan AllowedIPs = 192.0.2.1/24
. Pastikan untuk menentukan IP individual untuk rekan jarak jauh yang tidak menyampaikan lalu lintas dan hanya bertindak sebagai klien sederhana AllowedIPs = 192.0.2.3/32
.wg-quick up /full/path/to/wg0.conf
wg-quick up /full/path/to/wg0.conf
ping 192.0.2.3
memeriksa rute langsung ke peer dengan AllowedIPs = 192.0.2.3/32
terlebih dahulu, kemudian kembali ke server relai yang menerima IP di seluruh subnet # install on Ubuntu
sudo add-apt-repository ppa:wireguard/wireguard
apt install wireguard
# install on macOS
brew install wireguard-tools
# install on FreeBSD
pkg install wireguard
# install on iOS/Android using Apple App Store/Google Play Store
# install on other systems using https://www.wireguard.com/install/#installation
# to enable the kernel relaying/forwarding ability on bounce servers
echo " net.ipv4.ip_forward = 1 " | sudo tee -a /etc/sysctl.conf
echo " net.ipv4.conf.all.proxy_arp = 1 " | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf
# to add iptables forwarding rules on bounce servers
sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADE
nano wg0.conf # can be placed anywhere, must be referred to using absolute path (usually placed in /etc/wireguard/wg0.conf on most Linux systems)
# generate private key
wg genkey > example.key
# generate public key
wg pubkey < example.key > example.key.pub
wg-quick up /full/path/to/wg0.conf
wg-quick down /full/path/to/wg0.conf
# Note: you must specify the absolute path to wg0.conf, relative paths won't work
# If wg0.conf is in /etc/wireguard you can use the simpler:
wg-quick up wg0
# start/stop VPN network interface
ip link set wg0 up
ip link set wg0 down
# register/unregister VPN network interface
ip link add dev wg0 type wireguard
ip link delete dev wg0
# register/unregister local VPN address
ip address add dev wg0 192.0.2.3/32
ip address delete dev wg0 192.0.2.3/32
# register/unregister VPN route
ip route add 192.0.2.3/32 dev wg0
ip route delete 192.0.2.3/32 dev wg0
# show system LAN and WAN network interfaces
ip address show
# or if ip is not available:
ifconfig
# show system VPN network interfaces
ip link show wg0
# or
ifconfig wg0
# show WireGuard VPN interfaces
wg show all
wg show wg0
# show public IP address
ip address show eth0
# or
ifconfig eth0
# or
dig -4 +short myip.opendns.com @resolver1.opendns.com
# show VPN IP address
ip address show wg0
# show WireGuard routing table and peer connections
wg show
wg show wg0 allowed-ips
# show system routing table
ip route show table main
ip route show table local
# show system route to specific address
ip route get 192.0.2.3
Untuk mengaktifkan proses logging tambahan:
modprobe wireguard
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control
Untuk mengikuti log:
dmesg -wH
Sistem dengan kernel modern dan Safe Boot mungkin perlu menonaktifkan Verifikasi Tanda Tangan DKMS Boot Aman untuk mengizinkan akses ke log kernel.
mokutil --disable-verification
reboot
# check that the main relay server is accessible directly via public internet
ping public-server1.example-vpn.dev
# check that the main relay server is available via VPN
ping 192.0.2.1
# check that public peers are available via VPN
ping 192.0.2.2
# check that remote NAT-ed peers are available via VPN
ping 192.0.2.3
# check that NAT-ed peers in your local LAN are available via VPN
ping 192.0.2.4
# install iperf using your preferred package manager
apt/brew/pkg/opkg install iperf
# check bandwidth over public internet to relay server
iperf -s # on public relay server
iperf -c public-server1.example-vpn.dev # on local client
# check bandwidth over VPN to relay server
iperf -s # on public relay server
iperf -c 192.0.2.1 # on local client
# check bandwidth over VPN to remote public peer
iperf -s # on remote public peer
iperf -c 192.0.2.2 # on local client
# check bandwidth over VPN to remote NAT-ed peer
iperf -s # on remote NAT-ed peer
iperf -c 192.0.2.3 # on local client
# check bandwidth over VPN to local NAT-ed peer (on same LAN)
iperf -s # on local NAT-ed peer
iperf -c 192.0.2.4 # on local client
Periksa kebocoran DNS menggunakan http://dnsleak.com, atau dengan memeriksa penyelesai pada pencarian:
dig example.com A
Konfigurasi WireGuard menggunakan sintaks INI, didefinisikan dalam file yang biasanya disebut wg0.conf
. Itu dapat ditempatkan di mana saja pada sistem, tetapi sering kali ditempatkan di /etc/wireguard/wg0.conf
.
Jalur konfigurasi ditentukan sebagai argumen saat menjalankan perintah wg-quick
, misalnya:
wg-quick up /etc/wireguard/wg0.conf
(selalu tentukan path lengkap dan absolut)
Nama file konfigurasi harus dalam format ${name of the new WireGuard interface}.conf
. Nama antarmuka WireGuard biasanya diawali dengan wg
dan diberi nomor mulai dari 0
, tetapi Anda dapat menggunakan nama apa pun yang cocok dengan regex ^[a-zA-Z0-9_=+.-]{1,15}$
.
File konfigurasi dapat memilih untuk menggunakan rangkaian opsi konfigurasi wg
yang terbatas, atau opsi wg-quick
yang lebih luas, bergantung pada perintah apa yang lebih disukai untuk memulai WireGuard. Dokumen ini merekomendasikan untuk tetap menggunakan wg-quick
karena memberikan pengalaman konfigurasi yang lebih kuat dan ramah pengguna.
Langsung ke definisi:
¶ [Interface]
¶ # Name = node1.example.tld
¶ Address = 192.0.2.3/32
¶ ListenPort = 51820
¶ PrivateKey = localPrivateKeyAbcAbcAbc=
¶ DNS = 1.1.1.1,8.8.8.8
¶ Table = 12345
MTU = 1500
¶ PreUp = /bin/example arg1 arg2 %i
¶ PostUp = /bin/example arg1 arg2 %i
¶ PreDown = /bin/example arg1 arg2 %i
¶ PostDown = /bin/example arg1 arg2 %i
¶ [Peer]
¶ # Name = node2-node.example.tld
AllowedIPs = 192.0.2.1/24
¶ Endpoint = node1.example.tld:51820
¶ PublicKey = remotePublicKeyAbcAbcAbc=
¶ PersistentKeepalive = 25
[Interface]
Menentukan pengaturan VPN untuk node lokal.
Contoh
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.5/32
PrivateKey = <private key for phone.example-vpn.dev>
[Interface]
# Name = public-server1.example-vpn.tld
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = <private key for public-server1.example-vpn.tld>
DNS = 1.1.1.1
# Name
Ini hanyalah komentar standar dalam sintaks INI yang digunakan untuk membantu melacak bagian konfigurasi mana yang dimiliki node mana, ini sepenuhnya diabaikan oleh WireGuard dan tidak berpengaruh pada perilaku VPN.
CATATAN: Semua komentar, termasuk # Name
, dihapus dari file .conf oleh operasi dan aplikasi tertentu. Jika Anda perlu mengidentifikasi rekan, pertimbangkan untuk menggunakan generator kunci rias wireguard, seperti wireguard-vanity-keygen atau wireguard-vanity-address, yang memungkinkan Anda memasukkan nama host ke dalam kunci publik host. Pembuatan kunci dapat memakan waktu beberapa menit (4 karakter), jam (5 karakter) atau lebih lama, jadi pertimbangkan untuk menggunakan singkatan untuk host dengan nama yang lebih panjang.
Address
Menentukan rentang alamat mana yang harus dirutekan lalu lintas oleh node lokal. Bergantung pada apakah node tersebut merupakan klien sederhana yang bergabung dengan subnet VPN, atau server pentalan yang menyampaikan lalu lintas antara beberapa klien, ini dapat diatur ke satu IP dari node itu sendiri (ditentukan dengan notasi CIDR), misalnya 192.0.2.3/32 ), atau rentang subnet IPv4/IPv6 yang lalu lintasnya dapat dirutekan oleh node.
Contoh
Node adalah klien yang hanya merutekan lalu lintas untuk dirinya sendiri
Address = 192.0.2.3/32
Node adalah server pentalan publik yang dapat menyampaikan lalu lintas ke rekan lainnya
Saat node bertindak sebagai server pentalan publik, node tersebut harus menyetelnya menjadi seluruh subnet yang dapat merutekan lalu lintas, bukan hanya satu IP saja.
Address = 192.0.2.1/24
Address = 192.0.2.1/24,2001:DB8::/64
ListenPort
Ketika node bertindak sebagai server pentalan publik, node tersebut harus melakukan hardcode pada port untuk mendengarkan koneksi VPN masuk dari internet publik. Klien yang tidak bertindak sebagai relay tidak boleh menetapkan nilai ini.
Contoh
ListenPort = 51820
ListenPort = 7000
PrivateKey
Ini adalah kunci pribadi untuk node lokal, tidak pernah dibagikan dengan server lain. Semua node harus memiliki kumpulan kunci pribadi, terlepas dari apakah itu server pentalan publik yang menyampaikan lalu lintas, atau klien sederhana yang bergabung dengan VPN.
Kunci ini dapat dihasilkan dengan wg genkey > example.key
Contoh
PrivateKey = somePrivateKeyAbcdAbcdAbcdAbcd=
DNS
Server DNS mengumumkan kepada klien VPN melalui DHCP, sebagian besar klien akan menggunakan server ini untuk permintaan DNS melalui VPN, namun klien juga dapat mengganti nilai ini secara lokal di node mereka
Contoh
DNS = 1.1.1.1
DNS = 1.1.1.1,8.8.8.8
Table
Secara opsional menentukan tabel perutean mana yang akan digunakan untuk rute WireGuard, tidak perlu dikonfigurasi untuk sebagian besar pengaturan.
Ada dua nilai khusus: 'off' menonaktifkan pembuatan rute secara keseluruhan, dan 'auto' (default) menambahkan rute ke tabel default dan memungkinkan penanganan khusus pada rute default.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
Contoh
Table = 1234
MTU
Secara opsional menentukan unit transmisi maksimum (MTU, alias ukuran paket/frame) yang akan digunakan saat menghubungkan ke peer, tidak perlu dikonfigurasi untuk sebagian besar pengaturan.
MTU secara otomatis ditentukan dari alamat titik akhir atau rute default sistem, yang biasanya merupakan pilihan yang masuk akal.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
Contoh
MTU = 1500
PreUp
Secara opsional, jalankan perintah sebelum antarmuka ditampilkan. Opsi ini dapat ditentukan beberapa kali, dengan perintah dijalankan sesuai urutan kemunculannya di file.
Contoh
PreUp = ip rule add ipproto tcp dport 22 table 1234
PostUp
Secara opsional, jalankan perintah setelah antarmuka ditampilkan. Opsi ini dapat muncul beberapa kali, seperti pada PreUp
Contoh
Baca nilai konfigurasi dari file atau output beberapa perintah
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command here)
Catat baris ke file
PostUp = echo "$(date +%s) WireGuard Started" >> /var/log/wireguard.log
Tekan webhook di server lain
PostUp = curl https://events.example.dev/wireguard/started/?key=abcdefg
Tambahkan rute ke tabel perutean sistem
PostUp = ip rule add ipproto tcp dport 22 table 1234
Tambahkan aturan iptables untuk mengaktifkan penerusan paket pada antarmuka WireGuard
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Paksa WireGuard untuk menyelesaikan ulang alamat IP untuk domain rekan
PostUp = resolvectl domain %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i yes
PreDown
Secara opsional, jalankan perintah sebelum antarmuka diturunkan. Opsi ini dapat muncul beberapa kali, seperti pada PreUp
Contoh
Catat baris ke file
PostDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log
Tekan webhook di server lain
PostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg
PostDown
Secara opsional, jalankan perintah setelah antarmuka diturunkan. Opsi ini dapat muncul beberapa kali, seperti pada PreUp
Contoh
Catat baris ke file
PostDown = echo "$(date +%s) WireGuard Stopped" >> /var/log/wireguard.log
Tekan webhook di server lain
PostDown = curl https://events.example.dev/wireguard/stopped/?key=abcdefg
Hapus aturan iptables yang meneruskan paket pada antarmuka WireGuard
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
Menentukan pengaturan VPN untuk rekan jarak jauh yang mampu merutekan lalu lintas untuk satu atau lebih alamat (itu sendiri dan/atau rekan lainnya). Rekan dapat berupa server pentalan publik yang meneruskan lalu lintas ke rekan lain, atau klien yang dapat diakses langsung melalui LAN/internet yang tidak berada di belakang NAT dan hanya merutekan lalu lintas untuk dirinya sendiri.
Semua klien harus didefinisikan sebagai rekan di server pentalan publik. Klien sederhana yang hanya merutekan lalu lintas untuk dirinya sendiri, hanya perlu menentukan rekan untuk relai publik, dan node lain dapat diakses secara langsung. Node yang berada di belakang NAT terpisah tidak boleh didefinisikan sebagai rekan di luar konfigurasi server publik, karena tidak ada rute langsung yang tersedia antara NAT terpisah. Sebaliknya, node di belakang NAT hanya boleh mendefinisikan server relai publik dan klien publik lainnya sebagai rekannya, dan harus menentukan AllowedIPs = 192.0.2.1/24
di server publik yang menerima rute dan memantulkan lalu lintas untuk subnet VPN ke server NAT jarak jauh. teman sebaya.
Singkatnya, semua node harus ditentukan di server pentalan utama. Pada server klien, hanya rekan yang dapat diakses langsung dari sebuah node yang harus didefinisikan sebagai rekan dari node tersebut, setiap rekan yang harus direlai oleh server pentalan harus ditinggalkan dan akan ditangani oleh rute penampung semua server relai.
Dalam konfigurasi yang diuraikan dalam dokumen di bawah ini, satu server public-server1
bertindak sebagai server pantulan relai untuk campuran klien yang dapat diakses publik dan klien yang memiliki NAT, dan rekan dikonfigurasikan pada setiap node sesuai dengan itu:
di public-server1
wg0.conf
(server pentalan)
Daftar [peer]
: public-server2
, home-server
, laptop
, phone
di public-server2
wg0.conf
(klien publik sederhana)
daftar [peer]
: public-server1
di home-server
wg0.conf
(klien sederhana di belakang NAT)
daftar [peer]
: public-server1
, public-server2
di laptop
wg0.conf
(klien sederhana di belakang NAT)
daftar [peer]
: public-server1
, public-server2
di phone
wg0.conf
(klien sederhana di belakang NAT)
daftar [peer]
: public-server1
, public-server2
Contoh
[Peer]
# Name = public-server2.example-vpn.dev
Endpoint = public-server2.example-vpn.dev:51820
PublicKey = <public key for public-server2.example-vpn.dev>
AllowedIPs = 192.0.2.2/32
[Peer]
# Name = home-server.example-vpn.dev
Endpoint = home-server.example-vpn.dev:51820
PublicKey = <public key for home-server.example-vpn.dev>
AllowedIPs = 192.0.2.3/32
[Peer]
# Name = public-server1.example-vpn.tld
Endpoint = public-server1.example-vpn.tld:51820
PublicKey = <public key for public-server1.example-vpn.tld>
# routes traffic to itself and entire subnet of peers as bounce server
AllowedIPs = 192.0.2.1/24
PersistentKeepalive = 25
# Name
Ini hanyalah komentar standar dalam sintaks INI yang digunakan untuk membantu melacak bagian konfigurasi mana yang dimiliki node mana, ini sepenuhnya diabaikan oleh WireGuard dan tidak berpengaruh pada perilaku VPN.
Endpoint
Mendefinisikan alamat yang dapat diakses publik untuk rekan jarak jauh. Hal ini tidak boleh dilakukan pada rekan-rekan yang menggunakan NAT atau rekan-rekan yang tidak memiliki pasangan IP:PORT stabil yang dapat diakses publik. Biasanya, ini hanya perlu ditentukan pada server pentalan utama, namun juga dapat ditentukan pada node publik lain dengan IP stabil seperti public-server2
pada contoh konfigurasi di bawah.
Contoh
Endpoint = 123.124.125.126:51820
(IPv6 juga didukung)Endpoint = public-server1.example-vpn.tld:51820
AllowedIPs
Ini mendefinisikan rentang IP yang mana peer akan merutekan lalu lintasnya. Pada klien sederhana, ini biasanya berupa satu alamat (alamat VPN dari klien sederhana itu sendiri). Untuk server pentalan, ini adalah rentang IP atau subnet yang mampu merutekan lalu lintas oleh server relai. Beberapa IP dan subnet dapat ditentukan menggunakan notasi IPv4 atau IPv6 CIDR yang dipisahkan koma (dari satu alamat /32 atau /128, hingga 0.0.0.0/0
dan ::/0
untuk menunjukkan rute default untuk mengirim semua lalu lintas internet dan VPN melalui rekan itu). Opsi ini dapat ditentukan beberapa kali.
Saat memutuskan bagaimana merutekan sebuah paket, sistem memilih rute yang paling spesifik terlebih dahulu, dan kembali ke rute yang lebih luas. Jadi untuk paket yang ditujukan ke 192.0.2.3
, sistem pertama-tama akan mencari iklan rekan 192.0.2.3/32
secara khusus, dan akan kembali ke iklan rekan 192.0.2.1/24
atau rentang yang lebih besar seperti 0.0.0.0/0
sebagai pilihan terakhir.
Contoh
peer adalah klien sederhana yang hanya menerima lalu lintas ke/dari dirinya sendiri
AllowedIPs = 192.0.2.3/32
peer adalah server relay yang dapat memantulkan lalu lintas VPN ke semua peer lainnya
AllowedIPs = 192.0.2.1/24
peer adalah server relai yang memantulkan semua lalu lintas internet & VPN (seperti proxy), termasuk IPv6
AllowedIPs = 0.0.0.0/0,::/0
peer adalah server relai yang merutekan ke dirinya sendiri dan hanya ke satu rekan lainnya
AllowedIPs = 192.0.2.3/32,192.0.2.4/32
peer adalah server relai yang merutekan dirinya sendiri dan semua node di LAN lokalnya
AllowedIPs = 192.0.2.3/32,192.168.1.1/24
PublicKey
Ini adalah kunci publik untuk node jarak jauh, dapat dibagikan dengan semua rekan. Semua node harus memiliki kumpulan kunci publik, terlepas dari apakah itu server pentalan publik yang menyampaikan lalu lintas, atau klien sederhana yang bergabung dengan VPN.
Kunci ini dapat dibuat dengan wg pubkey < example.key > example.key.pub
. (lihat di atas untuk mengetahui cara membuat kunci pribadi example.key
)
Contoh
PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=
PersistentKeepalive
Jika koneksi berpindah dari rekan yang diberi NAT ke rekan publik, node di belakang NAT harus secara teratur mengirimkan ping keluar untuk menjaga koneksi dua arah tetap hidup di tabel koneksi router NAT.
Contoh
simpul publik lokal ke simpul publik jarak jauh
Nilai ini tidak boleh ditentukan karena ping terus-menerus tidak diperlukan.
simpul publik lokal ke simpul jarak jauh dengan NAT
Nilai ini tidak boleh ditentukan karena merupakan tanggung jawab klien untuk menjaga koneksi tetap hidup karena server tidak dapat membuka kembali koneksi yang mati ke klien jika waktu habis.
node lokal dengan NAT ke node publik jarak jauh
PersistentKeepalive = 25
ini akan mengirimkan ping setiap 25 detik menjaga koneksi tetap terbuka di tabel koneksi router NAT lokal.
Contoh -contoh dalam dokumen ini terutama menggunakan IPv4, tetapi Wireguard secara asli mendukung notasi dan alamat CIDR IPv6 di mana -mana yang mendukung IPv4, cukup tambahkannya seperti halnya rentang atau alamat subnet lainnya.
Contoh
[Interface]
Address = 192.0.2.3/24, 2001:DB8::/64
[Peer]
...
AllowedIPs = 0.0.0.0/0, ::/0
Jika Anda ingin meneruskan semua lalu lintas internet melalui VPN, dan tidak hanya menggunakannya sebagai subnet server-ke-server, Anda dapat menambahkan 0.0.0.0/0, ::/0
ke definisi AllowedIPs
dari rekan yang ingin Anda pipa lalu lintas Anda.
Pastikan untuk juga menentukan IPv6 catchall bahkan ketika hanya meneruskan lalu lintas IPv4 untuk menghindari paket IPv6 yang membocorkan di luar VPN, lihat:
https://www.reddit.com/r/wireguard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_here_using_wireguard_to/
Contoh
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.3/32
PrivateKey = <private key for phone.example-vpn.dev>
[Peer]
# Name = public-server1.example-vpn.dev
PublicKey = <public key for public-server1.example-vpn.dev>
Endpoint = public-server1.example-vpn.dev:51820
AllowedIPs = 0.0.0.0/0, ::/0
Wireguard kadang -kadang dapat secara native membuat koneksi antara dua klien di belakang NATS tanpa perlu server relay publik, tetapi dalam kebanyakan kasus ini tidak mungkin. Koneksi nat-to-nat hanya dimungkinkan jika setidaknya satu host memiliki alamat IP yang stabil dan dapat diakses publik: port port yang dapat dikodekan sebelumnya, apakah itu menggunakan FQDN yang diperbarui dengan DNS dinamis, atau IP publik statis dengan dengan statis dengan Port NAT non-acak yang dibuka oleh paket keluar, apa pun berfungsi selama semua rekan dapat mengomunikasikannya sebelumnya dan tidak berubah begitu koneksi dimulai.
Port dan alamat yang diketahui perlu dikonfigurasi sebelumnya karena Wireguard tidak memiliki lapisan pensinyalan atau server setrum publik yang dapat digunakan untuk mencari host lain secara dinamis. WebRTC adalah contoh protokol yang secara dinamis dapat mengkonfigurasi koneksi antara dua NAT, tetapi ia melakukan ini dengan menggunakan server pensinyalan out-of-band untuk mendeteksi IP: kombo port dari setiap host. Wireguard tidak memiliki ini, sehingga hanya berfungsi dengan Endpoint
yang hardcoded + ListenPort
(dan PersistentKeepalive
sehingga tidak turun setelah tidak aktif).
Pelajari lebih lanjut dari Tailscale's Bible of Nat Traversal: https://tailscale.com/blog/how-nat-raversal-works/
Endpoint
yang hardcoded, dapat diakses secara langsung. Jika keduanya di belakang NAT tanpa alamat IP yang stabil, maka Anda harus menggunakan DNS dinamis atau solusi lain untuk memiliki domain/IP yang stabil dan dapat diakses untuk setidaknya satu rekan sejawatListenPort
yang hardcoded yang ditentukan, dan router NAT tidak boleh melakukan pengacakan port sumber UDP, jika tidak, paket pengembalian akan dikirim ke Hardcoded ListenPort
dan dijatuhkan oleh router, alih -alih menggunakan port acak yang ditetapkan oleh tersebut Nat di paket keluarPersistentKeepalive
yang diaktifkan pada semua rekan lain, sehingga mereka terus mengirim ping yang keluar untuk menjaga koneksi tetap ada di meja perutean NAT mereka Proses pengiriman paket awal yang ditolak, kemudian menggunakan fakta bahwa router kini telah membuat aturan penerusan untuk menerima tanggapan disebut "UDP Hole-Punching".
Saat Anda mengirim paket UDP, router (biasanya) membuat aturan sementara memetakan alamat sumber dan port ke alamat dan port tujuan, dan sebaliknya. Paket UDP yang kembali dari alamat tujuan dan port (dan tidak ada yang lain) diteruskan ke alamat sumber asli dan port (dan tidak ada yang lain). Ini adalah bagaimana sebagian besar aplikasi UDP berfungsi di belakang NATS (misalnya Bittorrent, Skype, dll). Aturan ini akan batas waktu setelah beberapa menit tidak aktif, sehingga klien di belakang NAT harus mengirim paket keluar reguler agar tetap terbuka (lihat PersistentKeepalive
).
Membuat ini bekerja ketika kedua titik akhir berada di belakang NATS atau firewall mengharuskan kedua titik akhir mengirim paket ke satu sama lain pada waktu yang hampir bersamaan. Ini berarti bahwa kedua belah pihak perlu mengetahui alamat IP publik yang lain dan nomor port sebelumnya, dalam kasus Wireguard ini dicapai oleh port yang telah ditentukan oleh coding yang keras untuk kedua belah pihak di wg0.conf
.
Pada 2019, banyak metode lubang-menempa lama yang digunakan yang digunakan untuk bekerja tidak lagi efektif. Salah satu contohnya adalah metode baru yang dipelopori oleh pwnat yang memalsukan waktu ICMP melebihi respons dari luar NAT untuk mendapatkan paket kembali ke rekan nat'ed, sehingga membocorkan port sumbernya sendiri. Port UDP hardcoding dan IP publik untuk kedua sisi koneksi NAT-to-NAT (seperti dijelaskan di atas) masih bekerja pada sebagian kecil jaringan. Secara umum semakin "perusahaan" jaringan, semakin kecil kemungkinan Anda dapat melubangi port UDP publik (Wi-Fi publik komersial dan data sel Nats sering tidak berfungsi misalnya).
Koneksi NAT-to-NAT tidak dimungkinkan jika semua titik akhir di belakang NAT dengan pengacakan port sumber UDP yang ketat (misalnya sebagian besar jaringan data seluler). Karena tidak ada pihak yang dapat menggunakan ListenPort
Hardcode dan menjamin bahwa NAT mereka akan menerima lalu lintas di port itu setelah ping yang keluar, Anda tidak dapat mengoordinasikan port untuk lubang-pukulan awal antara rekan dan koneksi akan gagal. Untuk alasan ini, Anda umumnya tidak dapat melakukan koneksi telepon ke telepon di jaringan LTE/3G, tetapi Anda mungkin dapat melakukan telepon-ke-kantor atau telepon ke rumah di mana kantor atau rumah memiliki IP publik yang stabil dan tidak 'T melakukan pengacakan port sumber.
Koneksi NAT-to-NAT dari belakang NATS dengan pengacakan sumber-port yang ketat dimungkinkan, Anda hanya perlu server pensinyalan untuk memberi tahu setiap sisi IP orang lain: tuple port. Berikut adalah beberapa implementasi yang mencapai ini dengan Wireguard:
Banyak pengguna melaporkan harus memulai kembali Wireguard setiap kali IP yang dinamis berubah, karena hanya menyelesaikan nama host pada startup. Untuk memaksa Wireguard untuk meneliti ulang nama host Endpoint
DNS dinamis lebih sering, Anda mungkin ingin menggunakan kait PostUp
untuk memulai kembali Wireguard setiap beberapa menit atau jam.
Anda dapat melihat apakah pengaturan hole -punching layak dengan menggunakan netcat pada klien dan server untuk melihat port dan pesanan koneksi apa yang berfungsi untuk mendapatkan koneksi dua arah terbuka: jalankan nc -v -u -p 51820 <address of peer2> 51820
( pada peer1) dan nc -v -u -l 0.0.0.0 51820
(pada peer2), lalu ketik kedua jendela untuk melihat apakah Anda bisa mendapatkan lalu lintas dua arah. Jika tidak berfungsi terlepas dari peer mana yang mengirimkan paket awal, maka Wireguard tidak akan dapat bekerja di antara rekan -rekan tanpa server estafet publik.
Koneksi NAT-to-NAT seringkali lebih tidak stabil dan memiliki keterbatasan lain, itulah sebabnya memiliki server public relay fallback masih disarankan.
Contoh
Peer1:
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer2.example-vpn.dev:12000
PersistentKeepalive = 25
Peer2:
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer1.example-vpn.dev:12000
PersistentKeepalive = 25
Catatan: Bagian ini adalah tentang IP rekan dinamis dalam subnet VPN, bukan alamat Endpoint
publik yang dinamis .
Alokasi dinamis IP peer (bukan hanya memiliki rekan tetap) sedang dikembangkan, implementasi WIP tersedia di sini: https://github.com/wireguard/wg-dynamic
Anda juga dapat membangun sistem alokasi dinamis sendiri dengan membaca dalam nilai IP dari file saat runtime dengan menggunakan PostUp
(lihat di bawah).
Contoh
[Interface]
...
PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command)
https://git.zx2c4.com/wireguard-go/about/
Implementasi Wireguard userland yang sesuai ditulis dalam go.
https://git.zx2c4.com/wireguard-rs/about/
Implementasi pengguna pengguna yang tidak lengkap dan tidak aman dari Wireguard yang ditulis dalam karat (tidak siap untuk umum).
https://git.zx2c4.com/wireguard-hs/about/
Implementasi pengguna pengguna yang tidak lengkap dan tidak aman dari Wireguard yang ditulis di Haskell (tidak siap untuk umum).
https://github.com/cloudflare/boringtun
Implementasi Wireguard independen yang tidak patuh, yang ditulis dalam karat (garpu terpisah yang ditulis oleh CloudFlare). Lihat https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/
Aplikasi Wireguard khusus platform
https://git.zx2c4.com/wireguard-ios/about/
https://git.zx2c4.com/wireguard-android/about/
https://git.zx2c4.com/wireguard-windows/about/
Semua implementasi ruang pengguna lebih lambat daripada versi C asli yang berjalan di kernel-land, tetapi memberikan manfaat lain dengan berjalan di Userland (misalnya wadah, kompatibilitas, dll.).
Ini adalah beberapa alat GUI dan CLI yang membungkus Wireguard untuk membantu dengan konfigurasi, penyebaran, manajemen kunci, dan koneksi.
Kredit untuk jalan pintas ini pergi ke: https://www.ericlight.com/new-things-i-didnt-now-about-wireguard.html
Wireguard akan mengabaikan rekan yang kunci publiknya cocok dengan kunci pribadi antarmuka. Jadi Anda dapat mendistribusikan satu daftar rekan di mana -mana, dan hanya menentukan [Interface]
secara terpisah pada setiap server.
Lihat: https://lists.zx2c4.com/pipermail/wireguard/2018-december/003703.html
Anda dapat menggabungkan ini dengan wg addconf
seperti ini:
Setiap rekan memiliki file sendiri /etc/wireguard/wg0.conf
, yang hanya berisi bagian [Interface]
.
Setiap rekan juga memiliki file bersama /etc/wireguard/peers.conf
, yang berisi semua rekan.
File wg0.conf
juga memiliki kait PostUp
: PostUp = wg addconf /etc/wireguard/peers.conf
.
Terserah Anda untuk memutuskan bagaimana Anda ingin berbagi peers.conf
. Saya tidak tahu, tapi cukup bagus bahwa Anda bisa dengan liar melemparkan bagian peer di sekitar, tanpa khawatir apakah itu sama dengan antarmuka.
Anda dapat mengatur nilai konfigurasi dari perintah sewenang -wenang atau dengan membaca nilai -nilai dari file, ini membuat manajemen kunci dan penyebaran lebih mudah karena Anda dapat membaca di kunci saat runtime dari layanan pihak ke -3 seperti Kubernetes Secrets atau AWS KMS.
Lihat: https://lists.zx2c4.com/pipermail/wireguard/2018-december/003702.html
Contoh
Anda dapat membaca dalam file sebagai PrivateKey
dengan melakukan sesuatu seperti:
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command)
Wireguard dapat dijalankan di Docker dengan berbagai tingkat kemudahan. Dalam kasus paling sederhana, --privileged
dan --cap-add=all
argumen dapat ditambahkan ke perintah Docker untuk memungkinkan pemuatan modul kernel.
Pengaturan bisa menjadi agak rumit dan sangat bergantung pada apa yang Anda coba capai. Anda dapat menjalankan Wireguard sendiri dalam wadah dan mengekspos antarmuka jaringan ke host, atau Anda dapat menjalankan Wireguard pada host yang memperlihatkan antarmuka ke wadah tertentu.
Lihat di bawah untuk contoh wadah Docker vpn_test
Routing semua lalu lintasnya melalui server relay Wireguard.
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
ports :
- 51820:51820/udp
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro
wg0.conf
:
[Interface]
# Name = relay1.wg.example.com
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = oJpRt2Oq27vIB5/ UVb7BRqCwad2YMReQgH5tlxz8YmI =
DNS = 1.1.1.1,8.8.8.8
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT ; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT ; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Name = peer1.wg.example.com
PublicKey = I+hXRAJOG/UE2IQvIHsou2zTgkUyPve2pzvHTnd/ 2Gg =
AllowedIPs = 192.0.2.2/32
Dalam contoh ini semua lalu lintas dari dalam wadah speedtest
akan melewati Wireguard VPN. Untuk hanya merutekan beberapa lalu lintas, ganti 0.0.0.0/0
di wg0.conf
di bawah ini dengan rentang subnet yang ingin Anda rute melalui VPN.
docker-compose.yml
:
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro
vpn_test :
image : curlimages/curl
entrypoint : curl -s http://whatismyip.akamai.com/
network_mode : ' service:wireguard '
wg0.conf
:
[Interface]
# Name = peer1.wg.example.com
Address = 192.0.2.2/32
PrivateKey = YCW76edD4W7nZrPbWZxPZhcs32CsBLIi1sEhsV/ sgk8 =
DNS = 1.1.1.1,8.8.8.8
[Peer]
# Name = relay1.wg.example.com
Endpoint = relay1.wg.example.com:51820
PublicKey = zJNKewtL3gcHdG62V3GaBkErFtapJWsAx+ 2um0c0B1s =
AllowedIPs = 192.0.2.1/24,0.0.0.0/0
PersistentKeepalive = 21
Untuk detail lebih lanjut, lihat bagian Bacaan lebih lanjut: Docker di bawah ini.
Untuk instruksi yang lebih rinci, lihat Panduan QuickStart dan referensi API di atas. Anda juga dapat mengunduh pengaturan contoh lengkap di sini: https://github.com/pirate/wireguard-example.
Sarankan perubahan: https://github.com/pirate/wireguard-docs/issues