wireguard docs
1.0.0
دليل API المرجعي لـ WireGuard بما في ذلك الإعداد والتكوين والاستخدام، مع أمثلة.
كل الفضل يعود إلى مشروع WireGuard، وzx2c4 والمساهمين مفتوحي المصدر للبرنامج الأصلي،
هذه هي محاولتي المنفردة غير الرسمية لتوفير المزيد من الوثائق الشاملة ومراجع واجهة برمجة التطبيقات والأمثلة.
مصدر هذه المستندات ومثال التعليمات البرمجية وأداة تعقب المشكلات: https://github.com/pirate/wireguard-docs إصدار صفحة HTML أجمل: https://docs.sweeting.me/s/wireguard
WireGuard هو حل VPN مفتوح المصدر مكتوب بلغة C بواسطة Jason Donenfeld وآخرين، ويهدف إلى إصلاح العديد من المشكلات التي ابتليت بها عروض VPN الحديثة الأخرى من خادم إلى خادم مثل IPSec/IKEv2 أو OpenVPN أو L2TP. تشترك في بعض أوجه التشابه مع عروض VPN الحديثة الأخرى مثل Tinc وMeshBird، وتحديدًا مجموعات التشفير الجيدة والحد الأدنى من التكوين. اعتبارًا من 2020-01، تم دمجه في الإصدار 5.6 من Linux kernel، مما يعني أنه سيتم شحنه مع معظم أنظمة Linux الجاهزة.
الروابط الرسمية
wg ، wg-quickأهداف WireGuard
راجع https://github.com/pirate/wireguard-docs للحصول على مصدر الكود والوثائق على سبيل المثال.
سواء كنت تعيش خلف سور الصين العظيم أو تحاول فقط تكوين شبكة بين خوادمك، فإن WireGuard يعد خيارًا رائعًا ويعمل بمثابة "كتلة ليغو" لبناء الشبكات (بنفس الطريقة التي تكون بها ZFS عبارة عن كتلة ليغو لبناء أنظمة الملفات ).
الأشياء التي لا يقوم بها WireGuard:
ولكن يمكنك كتابة الحلول الخاصة بك لهذه المشكلات باستخدام WireGuard أسفل الغطاء (مثل Tailscale أو AltheaNet).
هذه هي أسماء المضيفين التجريبية وأسماء النطاق وعناوين IP والنطاقات المستخدمة في الوثائق وأمثلة التكوينات. استبدلها بالقيم المفضلة لديك عند إجراء الإعداد الخاص بك.
example-vpn.dev بأي مجال يمكن الوصول إليه بشكل عام وتتحكم فيهpublic-server1 , public-server2 , home-server , laptop , phone يمكن تغييرها إلى أسماء المضيفين لجهازك192.0.2.1/24 ، 192.0.2.3 ، 192.0.2.3/32 ، 2001:DB8::/64 يمكن استبدالها بالشبكات الفرعية والعناوين المفضلة لديك (على سبيل المثال 192.168.5.1/24 )أينما ترى هذه السلاسل أدناه، يتم استخدامها فقط كقيم نائبة لتوضيح مثال وليس لها أي معنى خاص.
تأكد من تغيير عناوين IP في التكوينات الخاصة بك! إن الكتل المستخدمة في هذه المستندات محجوزة على سبيل المثال لأغراض بواسطة IETF ويجب عدم استخدامها مطلقًا في إعدادات الشبكة الحقيقية.
192.0.2.0/24 (TEST-NET-1) نطاق مثال IPv4 RFC57372001:DB8::/32 نطاق مثال IPv6 RFC3849 يمكنك استخدام أي نطاق خاص تريده لإعداداتك الخاصة، على سبيل المثال 10.0.44.0/24 ، فقط تأكد من أنها لا تتعارض مع أي من نطاقات شبكة LAN الفرعية التي يتواجد عليها أقرانك.
مضيف يتصل بشبكة VPN ويسجل عنوان شبكة فرعية لشبكة VPN مثل 192.0.2.3 لنفسه. يمكنه أيضًا توجيه حركة المرور بشكل اختياري لأكثر من عنوان (عناوين) خاص به عن طريق تحديد نطاقات الشبكة الفرعية في تدوين CIDR مفصولة بفواصل.
نظير/عقدة يمكن الوصول إليها بشكل عام وتعمل كنقطة احتياطية لترحيل حركة المرور لأقران VPN الآخرين خلف NAT. لا يعد خادم الارتداد نوعًا خاصًا من الخوادم، فهو نظير عادي تمامًا مثل جميع الخوادم الأخرى، والفرق الوحيد هو أنه يحتوي على عنوان IP عام ويتم تشغيل إعادة توجيه IP على مستوى kernel مما يسمح له بإرجاع حركة المرور مرة أخرى إلى شبكة VPN للعملاء الآخرين.
شاهد المزيد: https://tailscale.com/blog/how-nat-traversal-works/ (يستخدم Tailscale Wireguard أسفل الغطاء)
مجموعة من عناوين IP منفصلة عن الإنترنت العام، على سبيل المثال 192.0.2.1-255 أو 192.168.1.1/24. بشكل عام، يتم توفيره خلف NAT بواسطة جهاز توجيه، على سبيل المثال في شبكة الإنترنت المحلية في المكتب أو شبكة Wi-Fi المنزلية.
طريقة لتعريف الشبكة الفرعية وحجمها باستخدام "قناع"، قناع أصغر = المزيد من وحدات بت العنوان التي يمكن استخدامها بواسطة الشبكة الفرعية والمزيد من عناوين IP في النطاق. الأكثر شيوعًا:
192.0.2.1/32 (عنوان IP واحد، 192.0.2.1 ) قناع الشبكة = 255.255.255.255192.0.2.1/24 (255 عنوان IP من 192.0.2.0 - 192.0.2.255 ) قناع الشبكة = 255.255.255.0192.0.2.1/16 (65,536 عنوان IP من 192.0.0.0 - 192.0.255.255 ) قناع الشبكة = 255.255.0.0192.0.2.1/8 (16,777,216 عنوان IP من 192.0.0.0 - 192.255.255.255 ) قناع الشبكة = 255.0.0.00.0.0.1/0 (4,294,967,296 عنوان IP من 0.0.0.0 - 255.255.255.255 ) قناع الشبكة = 0.0.0.02001:DB8::/64https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
بالنسبة للأشخاص الذين بدأوا للتو، قد يبدو 192.0.2.1/32 طريقة غريبة ومربكة للإشارة إلى عنوان IP واحد. هذا التصميم جميل لأنه يسمح للأقران بكشف عناوين IP متعددة إذا لزم الأمر دون الحاجة إلى تدوينات متعددة. فقط اعلم أنه في أي مكان ترى شيئًا مثل 192.0.2.3/32 ، فهذا يعني في الواقع 192.0.2.3 .
شبكة فرعية تحتوي على عناوين IP خاصة يوفرها جهاز توجيه يقف أمامها ويقوم بترجمة عنوان الشبكة، ولا يمكن الوصول إلى العقد الفردية بشكل عام من الإنترنت، وبدلاً من ذلك يتتبع جهاز التوجيه الاتصالات الصادرة ويعيد توجيه الاستجابات إلى عنوان IP الداخلي الصحيح (مثل شبكات المكاتب القياسية) ، شبكات الواي فاي المنزلية، شبكات الواي فاي العامة المجانية، الخ)
العنوان الذي يمكن الوصول إليه بشكل عام: منفذ للعقدة، على سبيل المثال 123.124.125.126:1234 أو some.domain.tld:1234 (يجب أن يكون الوصول إليه عبر الإنترنت العام، ولا يمكن عمومًا أن يكون عنوان IP خاصًا مثل 192.0.2.1 أو 192.168.1.1 ما لم يمكن الوصول إليه مباشرة باستخدام هذا العنوان من قبل نظراء آخرين على نفس الشبكة الفرعية).
مفتاح WireGuard الخاص لعقدة واحدة، يتم إنشاؤه باستخدام: wg genkey > example.key (لا يترك العقدة التي تم إنشاؤها عليها مطلقًا)
مفتاح WireGuard العام لعقدة واحدة، تم إنشاؤه باستخدام: wg pubkey < example.key > example.key.pub (مشترك مع أقران آخرين)
خادم اسم المجال، يُستخدم لحل أسماء المضيفين لعناوين IP لعملاء VPN، بدلاً من السماح لطلبات DNS بالتسرب خارج VPN والكشف عن حركة المرور. التسريبات قابلة للاختبار من خلال http://dnsleak.com.
المرحلات العامة هي مجرد نظيرات VPN عادية قادرة على العمل كخادم ترحيل وسيط بين أي عملاء VPN خلف NATs، ويمكنهم إعادة توجيه أي حركة مرور لشبكة VPN الفرعية يتلقونها إلى النظير الصحيح على مستوى النظام (WireGuard لا يهتم بكيفية حدوث ذلك ، يتم التعامل معها بواسطة kernel net.ipv4.ip_forward = 1 وقواعد توجيه iptables).
إذا كان يمكن الوصول إلى جميع الأقران بشكل عام، فلا داعي للقلق بشأن المعاملة الخاصة لجعل أحدهم خادم ترحيل، فهو ضروري فقط إذا كان لديك أي أقران متصلين من خلف NAT.
يحتاج كل عميل فقط إلى تحديد الخوادم/الأقران التي يمكن الوصول إليها بشكل عام في التكوين الخاص به، وأي حركة مرور مرتبطة بأقران آخرين خلف NATs ستنتقل إلى شبكة VPN الفرعية الشاملة (على سبيل المثال 192.0.2.1/24 ) في مسار AllowedIPs العامة المسموح بها وسيتم إعادة توجيهها وفقًا لذلك بمجرد وصوله إلى خادم الترحيل.
باختصار: يجب تكوين الاتصالات المباشرة بين العملاء فقط، ولا ينبغي تعريف أي اتصالات تحتاج إلى ارتداد على أنها نظيرات، حيث يجب أن تتوجه إلى خادم الارتداد أولاً ويتم توجيهها من هناك مرة أخرى عبر VPN إلى العميل الصحيح.
يمكن بالتأكيد تحقيق طبولوجيا أكثر تعقيدًا، ولكن هذه هي طرق التوجيه الأساسية المستخدمة في إعدادات WireGuard النموذجية:
Endpoint المشفرة بحيث يتمكن WireGuard من الاتصال مباشرة بالمنفذ المفتوح وتوجيه حزم UDP بدون قفزات وسيطة.public-server2 )، حدد العقدة التي يمكن الوصول إليها بشكل عام باستخدام Endpoint مشفرة وعقدة NAT-ed بدونها. سيتم فتح الاتصال من عميل NAT -> العميل العام، ثم سيتم توجيه حركة المرور مباشرة بينهما في كلا الاتجاهين طالما ظل الاتصال نشطًا عن طريق أوامر ping PersistentKeepalive الصادرة من عميل NAT-ed.public-server1 ، وسيتم إعادة توجيه حركة المرور عبر خادم الارتداد الوسيط طالما كانت الاتصالات يتم الاحتفاظ بها على قيد الحياة. ستحظى المسارات الأكثر تحديدًا (وعادةً ما تكون أكثر مباشرة أيضًا) المقدمة من النظراء الآخرين بالأولوية عند توفرها، وإلا ستعود حركة المرور إلى المسار الأقل تحديدًا وتستخدم 192.0.2.1/24 جامع لإعادة توجيه حركة المرور إلى خادم الارتداد، حيث سيتم ذلك يتم توجيهه من خلال جدول توجيه نظام خادم الترحيل ( net.ipv4.ip_forward = 1 ) للتراجع عن VPN إلى النظير المحدد الذي يقبل التوجيهات لحركة المرور تلك. لا يقوم WireGuard تلقائيًا بالعثور على المسار الأسرع أو محاولة تكوين اتصالات مباشرة بين الأقران إذا لم يتم تحديده بالفعل، فهو ينتقل فقط من المسار الأكثر تحديدًا في [Peers] إلى الأقل تحديدًا.
يمكنك معرفة طريقة التوجيه التي يستخدمها WireGuard لعنوان معين عن طريق قياس أوقات اختبار الاتصال لمعرفة الطول الفريد لكل قفزة، وعن طريق فحص مخرجات:
wg show wg0يستخدم WireGuard حزم UDP مشفرة لجميع حركة المرور، ولا يوفر ضمانات حول تسليم الحزم أو طلبها، حيث يتم التعامل مع ذلك بواسطة اتصالات TCP داخل النفق المشفر.
مزيد من القراءة:
تدعي WireGuard أن الأداء أسرع من معظم حلول VPN المنافسة الأخرى، على الرغم من أن الأرقام الدقيقة يتم مناقشتها أحيانًا وقد تعتمد على ما إذا كان التسريع على مستوى الأجهزة متاحًا لبعض شفرات التشفير.
يتم تحقيق مكاسب أداء WireGuard من خلال التعامل مع التوجيه على مستوى kernel، وباستخدام مجموعات التشفير الحديثة التي تعمل على جميع المراكز لتشفير حركة المرور. يكتسب WireGuard أيضًا ميزة كبيرة باستخدام UDP مع عدم وجود ضمانات للتسليم/الطلب (مقارنة بشبكات VPN التي تعمل عبر TCP أو تنفذ آليات التسليم المضمونة الخاصة بها).
مزيد من القراءة:
يستخدم WireGuard البروتوكولات والأساسيات التالية لتأمين حركة المرور:
يعد تشفير WireGuard في الأساس بمثابة تجسيد لإطار عمل Trevor Perrin's Noise. إنها حديثة وبسيطة مرة أخرى. يمثل كل خيار VPN آخر فوضى من المفاوضات والمصافحة وأجهزة الحالة المعقدة. يشبه WireGuard Signal/Axolotl الخاص بشبكات VPN، إلا أنه أبسط بكثير وأسهل في التفكير (من الناحية المشفرة، في هذه الحالة) من بروتوكولات المراسلة ذات السقاطة المزدوجة. إنه في الأساس qmail لبرنامج VPN. وهو ما يقرب من 4000 سطر من التعليمات البرمجية. إنها أوامر متعددة من حيث الحجم أصغر من منافسيها.
https://news.ycombinator.com/item?id=14599834
مزيد من القراءة:
يتم تحقيق المصادقة في كلا الاتجاهين باستخدام زوج مفاتيح عام/خاص بسيط لكل نظير. يقوم كل نظير بإنشاء هذه المفاتيح أثناء مرحلة الإعداد، ويشارك المفتاح العام فقط مع أقرانه الآخرين.
ليست هناك حاجة إلى شهادات أخرى أو مفاتيح مشتركة مسبقًا بخلاف المفاتيح العامة/الخاصة لكل عقدة.
يمكن التعامل مع إنشاء المفاتيح وتوزيعها وإبطالها في عمليات نشر أكبر باستخدام خدمة منفصلة مثل Ansible أو Kubernetes Secrets.
بعض الخدمات التي تساعد في توزيع المفاتيح ونشرها:
يمكنك أيضًا قراءة المفاتيح من ملف أو عبر أمر إذا كنت لا تريد ترميزها في wg0.conf ، مما يجعل إدارة المفاتيح عبر خدمة الطرف الثالث أسهل بكثير:
[Interface]
...
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privkey)من الناحية الفنية، يمكن لخوادم متعددة مشاركة نفس المفتاح الخاص طالما أن العملاء غير متصلين بخادمين بنفس المفتاح في نفس الوقت. مثال على السيناريو الذي يكون فيه هذا إعدادًا معقولاً هو إذا كنت تستخدم DNS Round-Robin لموازنة التحميل بين خادمين يتظاهران بأنهما خادم واحد. ومع ذلك، في معظم الأوقات، يجب أن يكون لكل نظير زوج مفاتيح عام/خاص خاص به حتى لا يتمكن الزملاء من قراءة حركة مرور بعضهم البعض ويمكن إبطالها بشكل فردي.
نظرة عامة على العملية العامة:
apt install wireguard أو pkg/brew install wireguard-tools على كل عقدةwg genkey + wg pubkeywg0.conf WireGuard على خادم الترحيل الرئيسي[Interface] تأكد من تحديد نطاق CIDR لشبكة VPN الفرعية بأكملها عند تحديد العنوان الذي يقبل الخادم توجيهاته Address = 192.0.2.1/24[Peer] قم بإنشاء قسم نظير لكل عميل ينضم إلى VPN، باستخدام المفاتيح العامة البعيدة المقابلة لهwg0.conf على كل عقدة عميل[Interface] تأكد من تحديد عنوان IP واحد فقط لأقران العميل الذين لا يقومون بترحيل حركة المرور Address = 192.0.2.3/32 .[Peer] قم بإنشاء قسم نظير لكل نظير عام لا يتبع NAT، وتأكد من تحديد نطاق CIDR لشبكة VPN الفرعية بأكملها عند تحديد النظير البعيد الذي يعمل كخادم الارتداد المسموح به AllowedIPs = 192.0.2.1/24 . تأكد من تحديد عناوين IP فردية للأقران البعيدين الذين لا يقومون بترحيل حركة المرور ويعملون فقط كعملاء بسيطين AllowedIPs = 192.0.2.3/32 .wg-quick up /full/path/to/wg0.confwg-quick up /full/path/to/wg0.confping 192.0.2.3 من وجود مسار مباشر إلى نظير له AllowedIPs = 192.0.2.3/32 أولاً، ثم يعود مرة أخرى إلى خادم ترحيل يقبل عناوين IP في الشبكة الفرعية بأكملها # 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 MASQUERADEnano 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.pubwg-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لتمكين تشغيل التسجيل الإضافي:
modprobe wireguard
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/controlلمتابعة السجلات:
dmesg -wHقد تتطلب الأنظمة التي تحتوي على kernel الحديث والتمهيد الآمن تعطيل Secure Boot DKMS Signature Verification للسماح بالوصول إلى سجلات 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 تحقق من وجود تسربات DNS باستخدام http://dnsleak.com، أو عن طريق التحقق من أداة التحليل أثناء البحث:
dig example.com A تكوين WireGuard موجود في بناء جملة INI، ويتم تعريفه في ملف يُسمى عادةً wg0.conf . يمكن وضعه في أي مكان على النظام، ولكن غالبًا ما يتم وضعه في /etc/wireguard/wg0.conf .
يتم تحديد مسار التكوين كوسيطة عند تشغيل أي أمر wg-quick ، على سبيل المثال:
wg-quick up /etc/wireguard/wg0.conf (حدد دائمًا المسار الكامل والمطلق)
يجب أن يكون اسم ملف التكوين بالتنسيق ${name of the new WireGuard interface}.conf . عادةً ما تكون أسماء واجهة WireGuard مسبوقة بـ wg ومرقمة بدءًا من 0 ، ولكن يمكنك استخدام أي اسم يطابق التعبير العادي ^[a-zA-Z0-9_=+.-]{1,15}$ .
يمكن لملفات التكوين اختيار استخدام المجموعة المحدودة من خيارات تكوين wg ، أو خيارات wg-quick الأكثر اتساعًا، اعتمادًا على الأمر المفضل لبدء WireGuard. توصي هذه المستندات بالالتزام بـ wg-quick لأنه يوفر تجربة تكوين أكثر قوة وسهولة في الاستخدام.
انتقل إلى التعريف:
¶ [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]يحدد إعدادات VPN للعقدة المحلية.
أمثلة
[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 يُستخدم للمساعدة في تتبع قسم التكوين الذي ينتمي إلى أي عقدة، ويتم تجاهله تمامًا بواسطة WireGuard وليس له أي تأثير على سلوك VPN.
ملاحظة: تتم إزالة جميع التعليقات، بما في ذلك # Name ، من ملفات .conf بواسطة عمليات وتطبيقات معينة. إذا كنت بحاجة إلى تحديد الأقران، ففكر في استخدام مولد مفاتيح الغرور الخاص بـ wireguard، مثل wireguard-vanity-keygen أو wireguard-vanity-address، والذي سيسمح لك بتضمين اسم المضيف في المفتاح العام للمضيف. يمكن أن يستغرق إنشاء المفاتيح دقائق (4 أحرف)، أو ساعات (5 أحرف) أو أكثر، لذا فكر في استخدام اختصار للمضيفين ذوي الأسماء الأطول.
Addressيحدد نطاق العنوان الذي يجب على العقدة المحلية توجيه حركة المرور إليه. اعتمادًا على ما إذا كانت العقدة عميلًا بسيطًا ينضم إلى شبكة VPN الفرعية، أو خادمًا مرتدًا ينقل حركة المرور بين عملاء متعددين، يمكن تعيين ذلك إلى عنوان IP واحد للعقدة نفسها (محدد بتدوين CIDR)، على سبيل المثال 192.0.2.3/32 )، أو نطاق من شبكات IPv4/IPv6 الفرعية التي يمكن للعقدة توجيه حركة المرور إليها.
أمثلة
العقدة هي عميل يقوم بتوجيه حركة المرور لنفسه فقط
Address = 192.0.2.3/32
Node هو خادم ارتداد عام يمكنه نقل حركة المرور إلى أقرانه الآخرين
عندما تعمل العقدة كخادم ارتداد عام، يجب أن تقوم بتعيين هذا ليكون الشبكة الفرعية بأكملها التي يمكنها توجيه حركة المرور، وليس مجرد عنوان IP واحد لنفسها.
Address = 192.0.2.1/24
Address = 192.0.2.1/24,2001:DB8::/64ListenPortعندما تعمل العقدة كخادم ارتداد عام، يجب أن تقوم بترميز منفذ للاستماع إلى اتصالات VPN الواردة من الإنترنت العام. يجب على العملاء الذين لا يعملون كمرحلات عدم تعيين هذه القيمة.
أمثلة
ListenPort = 51820ListenPort = 7000PrivateKeyهذا هو المفتاح الخاص للعقدة المحلية، ولا تتم مشاركته مطلقًا مع خوادم أخرى. يجب أن تحتوي جميع العقد على مجموعة مفاتيح خاصة، بغض النظر عما إذا كانت خوادم ارتداد عامة تنقل حركة المرور، أو عملاء بسيطين ينضمون إلى VPN.
يمكن إنشاء هذا المفتاح باستخدام wg genkey > example.key
أمثلة
PrivateKey = somePrivateKeyAbcdAbcdAbcdAbcd=
DNSخادم (خوادم) DNS للإعلان لعملاء VPN عبر DHCP، سيستخدم معظم العملاء هذا الخادم لطلبات DNS عبر VPN، ولكن يمكن للعملاء أيضًا تجاوز هذه القيمة محليًا على العقد الخاصة بهم
أمثلة
DNS = 1.1.1.1DNS = 1.1.1.1,8.8.8.8Tableيحدد بشكل اختياري جدول التوجيه المطلوب استخدامه لمسارات WireGuard، وليس من الضروري تكوينه لمعظم عمليات الإعداد.
هناك قيمتان خاصتان: 'off' يعطل إنشاء المسارات تمامًا، و'auto' (الافتراضي) يضيف المسارات إلى الجدول الافتراضي ويتيح معالجة خاصة للمسارات الافتراضية.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
أمثلة
Table = 1234MTUيحدد بشكل اختياري الحد الأقصى لوحدة الإرسال (MTU، ويعرف أيضًا باسم حجم الحزمة/الإطار) لاستخدامها عند الاتصال بالنظير، وليس من الضروري تكوينه لمعظم الإعدادات.
يتم تحديد وحدة الإرسال الكبرى (MTU) تلقائيًا من عناوين نقطة النهاية أو المسار الافتراضي للنظام، وهو عادةً اختيار معقول.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
أمثلة
MTU = 1500PreUpاختياريًا، قم بتشغيل أمر قبل ظهور الواجهة. يمكن تحديد هذا الخيار عدة مرات، مع تنفيذ الأوامر بالترتيب الذي تظهر به في الملف.
أمثلة
PreUp = ip rule add ipproto tcp dport 22 table 1234 PostUpاختياريًا، قم بتشغيل أمر بعد ظهور الواجهة. يمكن أن يظهر هذا الخيار عدة مرات، كما هو الحال مع PreUp
أمثلة
اقرأ قيمة التكوين من ملف أو مخرجات بعض الأوامر
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command here)
تسجيل سطر إلى ملف
PostUp = echo "$(date +%s) WireGuard Started" >> /var/log/wireguard.log
اضغط على webhook على خادم آخر
PostUp = curl https://events.example.dev/wireguard/started/?key=abcdefg
إضافة مسار إلى جدول توجيه النظام
PostUp = ip rule add ipproto tcp dport 22 table 1234
قم بإضافة قاعدة iptables لتمكين إعادة توجيه الحزم على واجهة 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
فرض WireGuard على إعادة تحديد عنوان IP للمجال النظير
PostUp = resolvectl domain %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i yes
PreDownاختياريًا، قم بتشغيل أمر قبل إسقاط الواجهة. يمكن أن يظهر هذا الخيار عدة مرات، كما هو الحال مع PreUp
أمثلة
تسجيل سطر إلى ملف
PostDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log
اضغط على webhook على خادم آخر
PostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg
PostDownاختياريًا، قم بتشغيل أمر بعد إسقاط الواجهة. يمكن أن يظهر هذا الخيار عدة مرات، كما هو الحال مع PreUp
أمثلة
تسجيل سطر إلى ملف
PostDown = echo "$(date +%s) WireGuard Stopped" >> /var/log/wireguard.log
اضغط على webhook على خادم آخر
PostDown = curl https://events.example.dev/wireguard/stopped/?key=abcdefg
قم بإزالة قاعدة iptables التي تعيد توجيه الحزم على واجهة 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]يحدد إعدادات VPN لنظير بعيد قادر على توجيه حركة المرور لعنوان واحد أو أكثر (نفسه و/أو أقرانه الآخرين). يمكن أن يكون النظراء إما خادم ارتداد عام ينقل حركة المرور إلى أقران آخرين، أو عميل يمكن الوصول إليه مباشرة عبر شبكة LAN/إنترنت لا يتبع NAT ويقوم فقط بتوجيه حركة المرور لنفسه.
يجب تعريف كافة العملاء كأقران على خادم الارتداد العام. العملاء البسيطون الذين يوجهون حركة المرور لأنفسهم فقط، يحتاجون فقط إلى تحديد أقرانهم للمرحل العام، وأي عقد أخرى يمكن الوصول إليها مباشرة. لا ينبغي تعريف العقد الموجودة خلف NATs المنفصلة على أنها نظيرات خارج تكوين الخادم العام، حيث لا يتوفر مسار مباشر بين NATs المنفصلة. بدلاً من ذلك، يجب على العقد الموجودة خلف NAT أن تحدد فقط خوادم الترحيل العامة والعملاء العموميين الآخرين كأقران لها، ويجب أن تحدد AllowedIPs = 192.0.2.1/24 على الخادم العام الذي يقبل المسارات ويرتد حركة المرور لشبكة VPN الفرعية إلى NAT-ed البعيد أقرانهم.
باختصار، يجب تحديد جميع العقد على خادم الارتداد الرئيسي. في خوادم العملاء، يجب تعريف الأقران الذين يمكن الوصول إليهم مباشرة من العقدة فقط على أنهم أقران لتلك العقدة، ويجب استبعاد أي أقران يجب ترحيلهم بواسطة خادم مرتد وسيتم التعامل معهم من خلال المسار الشامل لخادم الترحيل.
في التكوين الموضح في المستندات أدناه، يعمل خادم واحد public-server1 كخادم ارتداد ترحيل لمزيج من العملاء الذين يمكن الوصول إليهم بشكل عام وعملاء NAT-ed، ويتم تكوين الأقران على كل عقدة وفقًا لذلك:
في public-server1 wg0.conf (خادم ترتد)
قائمة [peer] : public-server2 ، home-server ، laptop ، phone
في public-server2 wg0.conf (عميل عام بسيط)
قائمة [peer] : public-server1
في home-server wg0.conf (عميل بسيط خلف NAT)
قائمة [peer] : public-server1 ، public-server2
في laptop wg0.conf (عميل بسيط خلف NAT)
قائمة [peer] : public-server1 ، public-server2
في phone wg0.conf (عميل بسيط خلف NAT)
قائمة [peer] : public-server1 ، public-server2
أمثلة
[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 يُستخدم للمساعدة في تتبع قسم التكوين الذي ينتمي إلى أي عقدة، ويتم تجاهله تمامًا بواسطة WireGuard وليس له أي تأثير على سلوك VPN.
Endpoint يحدد العنوان الذي يمكن الوصول إليه بشكل عام للنظير البعيد. يجب ترك هذا الأمر للأقران الذين يعملون خلف NAT أو الأقران الذين ليس لديهم زوج IP: PORT مستقر يمكن الوصول إليه بشكل عام. عادةً، يحتاج هذا فقط إلى التحديد على خادم الارتداد الرئيسي، ولكن يمكن أيضًا تعريفه على العقد العامة الأخرى ذات عناوين IP الثابتة مثل public-server2 في مثال التكوين أدناه.
أمثلة
Endpoint = 123.124.125.126:51820 (IPv6 مدعوم أيضًا)Endpoint = public-server1.example-vpn.tld:51820AllowedIPs يحدد هذا نطاقات IP التي سيقوم النظير بتوجيه حركة المرور إليها. بالنسبة للعملاء البسيطين، يكون هذا عادةً عنوانًا واحدًا (عنوان VPN الخاص بالعميل البسيط نفسه). بالنسبة لخوادم الارتداد، سيكون هذا نطاقًا من عناوين IP أو الشبكات الفرعية التي يستطيع خادم الترحيل توجيه حركة المرور إليها. يمكن تحديد عناوين IP وشبكات فرعية متعددة باستخدام تدوين IPv4 أو IPv6 CIDR مفصول بفواصل (من عنوان /32 أو /128 واحد، وصولاً إلى 0.0.0.0/0 و ::/0 للإشارة إلى المسار الافتراضي لإرسال الكل حركة مرور الإنترنت وVPN من خلال هذا النظير). قد يتم تحديد هذا الخيار عدة مرات.
عند تحديد كيفية توجيه حزمة ما، يختار النظام المسار الأكثر تحديدًا أولاً، ثم يعود إلى المسارات الأوسع. لذا، بالنسبة للحزمة الموجهة إلى 192.0.2.3 ، سيبحث النظام أولاً عن إعلان نظير 192.0.2.3/32 على وجه التحديد، وسيعود إلى إعلان نظير 192.0.2.1/24 أو نطاق أكبر مثل 0.0.0.0/0 مثل الملاذ الأخير.
أمثلة
النظير هو عميل بسيط يقبل فقط حركة المرور من/إلى نفسه
AllowedIPs = 192.0.2.3/32
النظير هو خادم ترحيل يمكنه نقل حركة مرور VPN إلى جميع أقرانه الآخرين
AllowedIPs = 192.0.2.1/24
النظير هو خادم ترحيل يرتد كل حركة مرور الإنترنت وشبكة VPN (مثل الوكيل)، بما في ذلك IPv6
AllowedIPs = 0.0.0.0/0,::/0
النظير هو خادم ترحيل يقوم بالتوجيه إلى نفسه وإلى نظير واحد فقط
AllowedIPs = 192.0.2.3/32,192.0.2.4/32
النظير هو خادم ترحيل يقوم بالتوجيه إلى نفسه وجميع العقد الموجودة على شبكة LAN المحلية الخاصة به
AllowedIPs = 192.0.2.3/32,192.168.1.1/24
PublicKeyهذا هو المفتاح العام للعقدة البعيدة، ويمكن مشاركته مع جميع أقرانه. يجب أن تحتوي جميع العقد على مجموعة مفاتيح عامة، بغض النظر عما إذا كانت خوادم ارتداد عامة تنقل حركة المرور، أو عملاء بسيطين ينضمون إلى VPN.
يمكن إنشاء هذا المفتاح باستخدام wg pubkey < example.key > example.key.pub . (انظر أعلاه لمعرفة كيفية إنشاء المفتاح الخاص example.key )
أمثلة
PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=
PersistentKeepaliveإذا كان الاتصال ينتقل من نظير NAT-ed إلى نظير عام، فيجب على العقدة الموجودة خلف NAT إرسال اختبار ping صادر بانتظام للحفاظ على الاتصال ثنائي الاتجاه نشطًا في جدول اتصال جهاز توجيه NAT.
أمثلة
العقدة العامة المحلية إلى العقدة العامة البعيدة
يجب ترك هذه القيمة بدون تعريف حيث أنه ليست هناك حاجة إلى أوامر ping مستمرة.
العقدة العامة المحلية إلى عقدة NAT-ed البعيدة
يجب ترك هذه القيمة بدون تعريف حيث إنها مسؤولية العميل للحفاظ على الاتصال حيًا لأن الخادم لا يمكنه إعادة فتح اتصال ميت مع العميل إذا انتهت المهلة.
عقدة NAT-ed المحلية إلى العقدة العامة البعيدة
PersistentKeepalive = 25 سيؤدي هذا إلى إرسال اختبار ping كل 25 ثانية مع إبقاء الاتصال مفتوحًا في جدول اتصال جهاز توجيه NAT المحلي.
تستخدم الأمثلة الواردة في هذه المستندات بشكل أساسي IPv4 ، لكن Wireguard يدعم تدوين IPv6 CIDR ويتناول في كل مكان يدعمه IPv4 ، ما عليك سوى إضافتها كما تفعل أي نطاق أو عنوان شبكة فرعية أخرى.
مثال
[Interface]
Address = 192.0.2.3/24, 2001:DB8::/64
[Peer]
...
AllowedIPs = 0.0.0.0/0, ::/0 إذا كنت ترغب في إعادة توجيه جميع حركة المرور على الإنترنت من خلال VPN ، وليس فقط استخدامها كشبكة فرعية من الخادم إلى الخادم ، يمكنك إضافة 0.0.0.0/0, ::/0 إلى تعريف AllowedIPs حركة المرور الخاصة بك من خلال.
تأكد أيضًا من تحديد catchall IPv6 حتى عند إعادة توجيه حركة المرور IPv4 فقط من أجل تجنب تسرب حزم IPv6 خارج VPN ، راجع:
https://www.reddit.com/r/wireguard/comments/B0M5G2/IPV6_LEAKS_PSA_FOR_ANYONE_HERE_USING_WIREGUARD_TO/
مثال
[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 أحيانًا بإجراء اتصالات بين عميلين خلف NATS دون الحاجة إلى خادم ترحيل عام ، ولكن في معظم الحالات ، هذا غير ممكن. لا تكون اتصالات NAT-to-NAT ممكنة إلا إذا كان لدى مضيف واحد على الأقل عنوان IP مستقر ، يمكن الوصول إليه علنًا: زوج المنفذ الذي يمكن ترميزه في وقت مبكر ، سواء كان ذلك يستخدم FQDN محدثًا باستخدام DNS الديناميكي ، أو عنوان IP عام ثابت مع منفذ NAT غير العشوائي الذي تم افتتاحه بواسطة الحزم الصادرة ، أي شيء يعمل طالما أن جميع أقرانهم يمكنهم توصيله مسبقًا ولا يتغير بمجرد بدء الاتصال.
يجب تكوين منفذ وعنوان معروف في وقت مبكر لأن Wireguard لا يحتوي على طبقة إشارات أو خوادم صاعقة عامة يمكن استخدامها للبحث عن مضيفات أخرى ديناميكيًا. WEBRTC هو مثال على بروتوكول يمكنه تكوين اتصال ديناميكي بين اثنين من NATS ، لكنه يقوم بذلك باستخدام خادم إشارات خارج النطاق للكشف عن IP: COMBO PORT لكل مضيف. لا يحتوي Wireguard على هذا ، لذلك فهو يعمل فقط مع Endpoint متشددين + ListenPort ( PersistentKeepalive حتى لا تنخفض بعد عدم النشاط).
تعرف على المزيد من كتاب Tailscale's من Nat Traversal: https://tainscale.com/blog/how-nat-traversal-works/
Endpoint متشددة يمكن الوصول إليها مباشرة. إذا كانا خلف NATS بدون عناوين IP مستقرة ، فستحتاج إلى استخدام DNS ديناميكية أو حل آخر للحصول على مجال/IP مستقر ، يمكن الوصول إليه بشكل علني لما لا يقل عن نظير واحد على الأقلListenPort ، ويجب ألا يقوم جهاز توجيه NAT بإلغاء توزيع العشوائية لمصدر UDP ، وإلا سيتم إرسال حزم الإرجاع إلى ListenPort المتشددين وإسقاطه بواسطة جهاز التوجيه ، بدلاً من استخدام المنفذ العشوائي المعين بواسطة نات على الحزمة المنتهية ولايتهPersistentKeepalive مرافعة الإدانة على جميع أقرانهم الآخرين ، بحيث يرسلون باستمرار الأصوات الصادرة للحفاظ على الاتصالات مستمرة في طاولة توجيه NAT الخاصة بهم هذه العملية لإرسال حزمة أولية يتم رفضها ، ثم باستخدام حقيقة أن جهاز التوجيه قد أنشأ الآن قاعدة إعادة توجيه لقبول الاستجابات يسمى "UDP Hole Punching".
عند إرسال حزمة UDP إلى الخارج ، يقوم جهاز التوجيه (عادةً) بإنشاء قاعدة مؤقتة تقوم بتخطيط عنوان المصدر الخاص بك ومنفذه إلى عنوان المقصد والمنفذ ، والعكس صحيح. يتم تمرير حزم UDP التي تعود من عنوان الوجهة والمنفذ (وليس آخر) إلى عنوان المصدر الأصلي والمنفذ (ولا يوجد آخر). هذه هي الطريقة التي تعمل بها معظم تطبيقات UDP خلف NATS (مثل BitTorrent ، Skype ، إلخ). ستؤدي هذه القاعدة إلى مهلة بعد بضع دقائق من عدم النشاط ، لذلك يجب على العميل وراء NAT إرسال حزم صادرة منتظمة لإبقائها مفتوحة (انظر PersistentKeepalive ).
يتطلب الحصول على هذا العمل عندما يتطلب كلتا النقاطين خلف NATS أو جدران الحماية أن ترسل كلتا النقاطين حزمًا إلى بعضهما البعض في نفس الوقت تقريبًا. هذا يعني أن كلا الجانبين يحتاجون إلى معرفة عناوين IP العامة للبعض الآخر وأرقام المنافذ في وقت مبكر ، في حالة Wireguard ، يتم تحقيق ذلك من خلال المنافذ المعرفة مسبقًا لكلا الجانبين في wg0.conf .
اعتبارًا من عام 2019 ، لم تعد العديد من أساليب القضاء على الثقب القديم المستخدمة في العمل فعالة. ومن الأمثلة على ذلك طريقة جديدة رائدة من قبل PWNAT أن مزيف وقت ICMP تجاوز الاستجابة من خارج NAT للحصول على حزمة مرة أخرى إلى نظير nat'ed ، وبالتالي تسرب منفذ المصدر الخاص به. لا تزال منافذ UDP المتشددين و IPs العامة لكلا جانبي اتصال NAT-to-NAT (كما هو موضح أعلاه) يعمل على نسبة مئوية صغيرة من الشبكات. بشكل عام ، كلما كانت الشبكة أكثر "مؤسسة" ، كلما قل احتمال أن تتمكن من ثقب منافذ UDP العامة (Wi-Fi التجاري وبيانات الخلايا NATS غالبًا ما لا تعمل على سبيل المثال).
لا يمكن اتصالات NAT-to-NAT إذا كانت جميع نقاط النهاية وراء NAT's مع توزيع العشوائية المصدر الصارم لمنفذ UDP (على سبيل المثال معظم شبكات البيانات الخلوية). نظرًا لأن أياً من الجانبين قادرين على ترميز ListenPort وضمان أن NAT سوف يقبل حركة المرور على هذا المنفذ بعد PING الصادر ، لا يمكنك تنسيق منفذ للثقب الأولي بين الأقران والاتصالات سيفشل. لهذا السبب ، لا يمكنك عمومًا القيام بوصلات من الهاتف إلى الهاتف على شبكات LTE/3G ، ولكن قد تتمكن "ر القيام بمنفذ العشوائية.
من الممكن توصيل اتصالات NAT-to-Nat من خلف NATS مع العشوائية المصدر الصارمة ، فقط ، تحتاج فقط إلى خادم إشارات لإخبار كل جانب عن IP: منفذ. فيما يلي بعض التطبيقات التي تحقق ذلك باستخدام Wireguard:
يشير العديد من المستخدمين إلى أن يضطروا إلى إعادة تشغيل Wireguard كلما تغيرت IP ديناميكية ، حيث إنه يحل فقط أسماء المضيف عند بدء التشغيل. لإجبار Wireguard على إعادة استئناف أسماء مضيف Endpoint DNS الديناميكية في كثير من الأحيان ، قد ترغب في استخدام خطاف PostUp بعد إعادة تشغيل الأسلاك كل بضع دقائق أو ساعات.
يمكنك معرفة ما إذا كان إعداد حملة الثقب ممكنًا باستخدام NetCat على العميل والخادم لمعرفة ما تعمل المنافذ وطلب الاتصال على فتح اتصال ثنائي الاتجاه: تشغيل nc -v -u -p 51820 <address of peer2> 51820 ( على PEER1) و nc -v -u -l 0.0.0.0 51820 (على PEER2) ، ثم اكتب في كلا النوافذ لمعرفة ما إذا كان يمكنك الحصول على حركة مرور ثنائية الاتجاه ذاهب. إذا لم ينجح الأمر بغض النظر عن Peer الذي يرسل الحزمة الأولية ، فلن يكون WireGuard غير قادر على العمل بين أقرانهم بدون خادم ترحيل عام.
غالبًا ما تكون اتصالات NAT-to-Nat غير مستقرة ولديها قيود أخرى ، وهذا هو السبب في أن الحصول على خادم ترحيل عام احتياطي لا يزال ينصح.
مثال
PEER1:
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer2.example-vpn.dev:12000
PersistentKeepalive = 25PEER2:
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer1.example-vpn.dev:12000
PersistentKeepalive = 25 ملاحظة: يدور هذا القسم حول IPS Dynamic Peer داخل الشبكة الفرعية VPN ، وليس عناوين Endpoint العامة الديناميكية .
يتم تطوير التخصيص الديناميكي لـ Peer IPS (بدلاً من وجود أقران ثابتة فقط) ، يتوفر تطبيق WIP هنا: https://github.com/wireguard/wg-dynamic
يمكنك أيضًا إنشاء نظام تخصيص ديناميكي بنفسك عن طريق القراءة في قيم IP من الملفات في وقت التشغيل باستخدام PostUp (انظر أدناه).
مثال
[Interface]
...
PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command) https://git.zx2c4.com/wireguard-go/about/
تطبيق Userland Wireguard المتوافق مكتوبة في GO.
https://git.zx2c4.com/wireguard-rs/about/
تطبيق غير مكتمل وغير آمن من Wireguard مكتوب في Rust (غير جاهز للجمهور).
https://git.zx2c4.com/wireguard-hs/about/
تطبيق غير مكتمل وغير آمن من WireGuard مكتوب في Haskell (غير جاهز للجمهور).
https://github.com/cloudflare/boringtun
تطبيق غير متوافق ومستقل للأسلاك مكتوبة في الصدأ (شوكة منفصلة كتبها CloudFlare). انظر https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/
تطبيقات الأسلاك الخاصة بالمنصة
https://git.zx2c4.com/wireguard-ios/about/
https://git.zx2c4.com/wireguard-droid/about/
https://git.zx2c4.com/wireguard-windows/about/
جميع تطبيقات مساحة المستخدمين أبطأ من الإصدار C الأصلي الذي يعمل في kernel-land ، ولكنه يوفر فوائد أخرى عن طريق التشغيل في Userland (على سبيل المثال حاوية أسهل ، توافق ، إلخ).
هذه هي بعض أدوات واجهة المستخدم الرسومية و CLI التي تلتزم حارس الأسلاك للمساعدة في التكوين والنشر وإدارة المفاتيح والاتصال.
يعود الفضل في هذه الاختصارات إلى: https://www.ericlight.com/new-things-i-didnt-know-about-wireguard.html
سوف يتجاهل Wireguard نظيرًا يطابق مفتاحه العام للمفتاح الخاص للواجهة. حتى تتمكن من توزيع قائمة واحدة من أقرانها في كل مكان ، وتحديد [Interface] بشكل منفصل على كل خادم.
انظر: https://lists.zx2c4.com/pipermail/wireguard/2018-december/003703.html
يمكنك الجمع بين هذا مع wg addconf مثل هذا:
كل نظير له ملف /etc/wireguard/wg0.conf ، والذي يحتوي فقط على قسم [Interface] .
يحتوي كل نظير أيضًا على ملف /etc/wireguard/peers.conf ، والذي يحتوي على جميع أقرانهم.
يحتوي ملف wg0.conf أيضًا على خطاف PostUp : PostUp = wg addconf /etc/wireguard/peers.conf .
الأمر متروك لك أن تقرر كيف تريد مشاركة peers.conf . أنا لا أتعامل مع ، لكن من الرائع أن تتمكن من القضاء على قسم نظير بعنف ، دون القلق مما إذا كان هو نفسه الواجهة.
يمكنك تعيين قيم التكوين من أوامر تعسفية أو عن طريق القراءة في القيم من الملفات ، مما يجعل الإدارة المفتاح والنشر أسهل بكثير حيث يمكنك القراءة في مفاتيح وقت التشغيل من خدمة الطرف الثالث مثل أسرار Kubernetes أو AWS KMS.
انظر: https://lists.zx2c4.com/pipermail/wireguard/2018-december/003702.html
مثال
يمكنك القراءة في ملف باعتباره PrivateKey من خلال القيام بشيء مثل:
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command)
يمكن تشغيل Wireguard في Docker بدرجات متفاوتة من السهولة. في أبسط الحالات ، --privileged إضافة --cap-add=all الوسائط إلى أوامر Docker لتمكين تحميل وحدة kernel.
يمكن أن تصبح الإعدادات معقدة إلى حد ما وتعتمد بشكل كبير على ما تحاول تحقيقه. يمكنك تشغيل Wireguard نفسه في حاوية وفضح واجهة شبكة للمضيف ، أو يمكنك تشغيل Wireguard على المضيف الذي يعرض واجهة لحاويات محددة.
انظر أدناه للحصول على مثال على حاوية Docker vpn_test توجيه جميع حركة المرور من خلال خادم ترحيل 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 في هذا المثال ، ستذهب جميع حركة المرور من داخل حاوية speedtest من خلال VPN من Wireguard. لتوجيه بعض حركة المرور فقط ، استبدل 0.0.0.0/0 في wg0.conf أدناه مع النطاقات الشبكة الفرعية التي تريد توجيهها عبر 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لمزيد من التفاصيل ، راجع قسم القراءة الإضافية: Docker أدناه.
لمزيد من التعليمات التفصيلية ، راجع دليل QuickStart و API أعلاه. يمكنك أيضًا تنزيل إعداد مثال كامل هنا: https://github.com/pirate/wireguard-example.
اقترح تغييرات: https://github.com/pirate/wireguard-docs/issues
