IPsec şlüzəsi üçün WireGuard profili: əvəzində nələri soruşmalı

Səssiz şlüzlə əl sıxma fasilələri adətən heç vaxt görüşməyən iki protokol deməkdir. WireGuard peer-i Noise danışır, IPsec şlüzü isə IKE gözləyir. Düzgün ünvan və port bunu dəyişmir.

Endpoint-i profildə təkrar istifadə etmək ikisini birləşdirmir. Növbəti addım şlüzü idarə edənə müraciət etməkdir.

Birinci sorğu: protokol versiyası

IPsec tək bir iş axını deyil, bir ailə adlandırır. IKEv2 və IKEv1 mübadilələri, autentifikasiya seçimləri və şəbəkə dəyişikliyi zamanı davranışları ilə fərqlənir. Yalnız IKEv1-i sonlandıran şlüz, IKEv2 təklif edəndən tamamilə fərqli davranacaq. Müştəri konfiqurasiyası da buna uyğun fərqlənir.

Xidmətin hansı versiyanı sonlandırdığını və standartlara əsaslanan tətbiq, yoxsa öz müştərisi olan satıcı variantı işlətdiyini soruşun. Əməliyyat sistemi menyuları çox vaxt bu cavabı bir etiketin arxasında gizlədir. Etiket protokol deyil.

İkinci sorğu: müştərinin autentifikasiya üsulu

Autentifikasiya əsl işin çoxunun yerləşdiyi yerdir. Xidmət müəyyən genişləndirilmiş açar istifadəsi olan maşın sertifikatı, istifadəçi sertifikatı, IKEv2 üzərində EAP üsulu və ya kimliyə bağlanmış əvvəlcədən paylaşılmış açar gözləyə bilər. Hansının tətbiq olunduğu müştərinin nəyə ehtiyacı olduğunu müəyyən edir.

WireGuard özəl açarı bunların heç biri deyil. O, bir konkret əl sıxmada istifadə olunan Curve25519 açarıdır. Heç bir çevirmə onu sertifikata və ya EAP etimadnaməsinə çevirmir. Əksini iddia edən alət faylı yenidən adlandırır və ya əlaqəsiz bir şey yaradır.

RFC 7296-dakı IKEv2 spesifikasiyası həmin versiyanın tətbiqinin nəyi dəstəkləməli olduğunu təsvir edir. Bu, qeyri-müəyyən operator cavabı üçün istinad, müştəri konfiqurasiyası bələdçisi deyil.

Üçüncü sorğu: etibarlı kimlik və təyinatlar

Şlüz kimliyini müştərinin görməli olduğu şəkildə, onu təsdiqləyən etimad ankeri ilə birlikdə soruşun. Sonra xidmətin hansı özəl aralıqları və həllediciləri itələdiyini soruşun. Bu iki cavab tunelin əslində nə daşıdığını müəyyən edir.

Onlarsız işləyən bir bağlantı yenə də tapşırığı yerinə yetirə bilməz. İtilən həlledici olmadan qalxan tunel daxili adları cavabsız qoyur. Çatışmayan trafik seçicisi əl sıxma uğurlu olsa da təyinatı tuneldən kənarda qoyur.

Endpoint yoxlaması müştəri xətasından fərqli suala cavab verir. Birləşmə olmadan əlçatan port autentifikasiyaya, əlçatmayan port isə yola işarə edir.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Müştəridə hər hansı dəyişiklik etməzdən əvvəl bu yoxlamanı aparın. Portlar cavab verir və birləşmə yenə uğursuz olursa, problem etimadnamələrdə və ya siyasətdədir. Heç cavab vermirlərsə, heç bir profil düzəlişi kömək etməyəcək.

Hər iki protokol birlikdə mövcud olmalı olduqda

Hər iki şəbəkəni idarə etmək hər iki protokolu saxlamaq üçün ağlabatan səbəbdir. Adi dizayn WireGuard və IPsec-i ayrı interfeyslərdə və ya ayrı şlüzlərdə sonlandırır. Təsdiqlənmiş trafik sonra onların arasında marşrutlaşdırılır.

Bu dizayn etimad və avtorizasiya sərhədi yaradır və bu şəkildə yazılmalıdır. Hansı peer-lərin keçə biləcəyi, hansı istiqamətdə və kimin siyasəti altında olması marşrutlaşdırma və firewall qərarıdır. Heç bir protokol bunu təmin etmir.

Bu olmadığı şey şəffaf çevirmədir. WireGuard üzərindən gələn trafik IPsec tunelinə yenidən yönəldilir və aradakı hər siyasət ona tətbiq olunur.

Əvvəlcə serverin protokol və autentifikasiya tələblərini dəqiqləşdirin. Sonra operatorun dəstəklədiyi müştərini və qeydiyyat yolunu istifadə edin və bu zaman özəl açarları veb çeviricilərdən uzaq tutun.