Tek bir yolu kanıtlayan iki peer'lik WireGuard testi nasıl kurulur

Bir tünel, bir adres çifti, bir izin verilen kaynak. Asgari bir WireGuard temeli, sonraki her yönlendirme, NAT veya DNS değişikliğini görünür kılar.

Varsayılan rota, LAN öneki, DNS ve güvenlik duvarı istisnası taşıyan bir WireGuard testi hangisinin bozulduğunu söyleyemez. Testi iki peer'e, bir adres çiftine ve tek bir izin verilen hizmete indirin; hatanın saklanacak yeri kalmaz. Sıkıcı temel, teşhisin kendisidir. Önce onu kurun; on beş dakika sürer ve yoksa tahminle geçireceğiniz öğleden sonrayı kurtarır.

Temelin kanıtladığı şey çoğu insanın beklediğinden dardır. İki kimliğin anlaştığını, UDP'nin dinleyen porta ulaştığını ve izin verilen tek bir hedefin bir isteği taşıdığını kanıtlar. Yönlendirme, NAT, LAN rotaları ve DNS sonradan tek tek eklenen ayrı özelliklerdir.

Anahtarlar, adresler ve tek endpoint

Her sistemde bir anahtar çifti üretin ve aralarında yalnızca açık yarıları taşıyın. wg genkey | tee privatekey | wg pubkey > publickey belgelenmiş tek satırlık komuttur ve özel anahtarı sonradan koruyabileceğiniz bir dosyada bırakır. Tünel adreslerini sahip olduğunuz başka hiçbir yapılandırmada görünmeyen bir aralıktan seçin, örneğin 10.99.0.1/24 ve 10.99.0.2/24. Hangi adresin hangi makineye ait olduğunu yazın, çünkü sonraki her kontrol bu eşlemeye bağlıdır.

Özel anahtarlar asla seyahat etmez. Bir testin bir anahtarı karşı tarafa kopyalaması gerekiyorsa, test zaten yanlış gitmiştir. İki sistem NAT arkasındaysa en az biri erişilebilir bir UDP portuna ihtiyaç duyar, diğeri ona işaret eden bir Endpoint taşır; genel adres ve port ise 51820 hakkındaki varsayımlarınızda değil, notlarınızda olmalıdır.

Farklı bir dış portu eşleyen port yönlendirme, Endpoint buna uyduğu sürece iyi çalışır. Buradaki uyuşmazlıklar hata değil sessizlik üretir, bu yüzden kabloda hata ayıklamadan önce kâğıt üzerinde kontrol etmeye değer.

wg'ye ait alanlar ve ait olmayanlar

Çekirdek alan kümesi küçüktür: Interface altında PrivateKey ve ListenPort, Peer altında PublicKey, AllowedIPs ve Endpoint. Address ve DNS wg'nin kendisine değil wg-quick'e aittir ve bu ayrım, aynı yapılandırma başka bir araca taşındığı anda ısırır.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs aynı anda iki iş yapar. Hangi hedeflerin tünele gireceğini seçer ve peer'e varışta bu kaynak adresleri kullanma yetkisi verir. Bu nedenle karşı taraftaki ayna girdisi tünel adresinizi tam olarak adlandırmalıdır; yanlış peer için bir /32 yönlendirme sorunu olarak okunur ve yetkilendirme sorunu gibi davranır. WireGuard hızlı başlangıç alan adlarını karşılaştırmak isterseniz aynı iki peer biçimini kurallı ifadeyle gösterir.

Simge yerine el sıkışmayı okumak

Arabirimi sahibi olan şey üzerinden kaldırın, sonra durum ışığı yerine durumu okuyun. wg show her peer için son el sıkışmayı bayt sayaçlarıyla birlikte yazdırır ve son birkaç dakika içindeki el sıkışma anahtarların, endpoint'in ve UDP yolunun hepsinin çalıştığı anlamına gelir. Yalnızca tek yönde artan bir sayaç kendi yanıtıdır ve hiç gerçekleşmeyen el sıkışmayla aynı arıza değildir.

İki arıza farklı incelemeler gerektirir. Hiç el sıkışma olmaması anahtar uyuşmazlığına, yanlış Endpoint'e, engellenmiş UDP'ye veya el sıkışmanın kendisini düşüren güvenlik duvarına işaret eder. El sıkışma başarılı olurken verinin hiçbir yere gitmemesi AllowedIPs'e, tünel adresinde dinlemeyen bir hizmete veya portu LAN için kabul edip tünel arabirimi için kabul etmeyen ana makine güvenlik duvarına işaret eder. Bunlar sistemin farklı yarılarıdır ve temel, kuralları değiştirmeye başlamadan önce onları ayırır.

İzin verilen tek hizmeti kanıtlamak, ardından ters yön

Diğer peer'in tünel adresine yanıt vermesi gereken bir hizmete istek gönderin ve ping'den daha iyisini seçin. Eksik bir ICMP yanıtı tünel arızası değil ana makine filtresi olabilir, bu yüzden sessiz bir ping iki yönü de kanıtlamaz. Açık olduğunu bildiğiniz bir porta TCP bağlantısı veya veri döndüren bir istek, yorumlayabileceğiniz bir yanıt verir.

Ters yönü kendi sonucu olan ayrı bir test olarak çalıştırın, çünkü iki yönün ayrı güvenlik duvarı ve AllowedIPs girdileri vardır ve bağımsız olarak başarısız olabilirler. El sıkışma çalışıyor ama istek çalışmıyorsa sorun tünelde değil veri yolundadır: AllowedIPs, dinleyen hizmet veya ana makine güvenlik duvarı. Yönlendirme, NAT veya DNS eklemeden önce bunu düzeltin, yoksa öğleden sonrayı hiç suçlu olmayan bir özelliğin hatalarını ayıklayarak geçirirsiniz.

Temeli referans olarak korumak

Çalışan topolojiyi ve profil kaynağını geri yükleyebileceğiniz bir yerde saklayın ve bunları genel bir hizmetle eşitlenen her dizinin dışında tutun. Sonra her seferinde bir özellik ekleyin ve her birinden sonra özgün isteği yineleyin: yönlendirme, NAT, bir LAN rotası ve ancak ondan sonra DNS. Testi bozan her ek artık tanımlanabilir, çünkü başka hiçbir şey hareket etmedi.

Yalnızca bir simgeyi yeşile çeviren bir temel, sonraki arızaya hangi ekin neden olduğu konusunda size hiçbir şey söylemedi. Tek izin verilen yolu referans olarak çalışır durumda tutun ve sonraki her değişiklik ona göre ölçülür.

İlgili makaleler