İç-içə WireGuard: orta keçid öz portuna cavab verə bilmir
Orta keçid hər şeyi bir tunelə göndərdikdə, daxil olan xidmətinə cavablar yanlış yolla çıxır. İnterfeysdə mənbə portu qaydası bunu düzəldir.
Üç WireGuard keçidi ümumi ünvanı olmayan bir şəbəkəyə çatır, sonra isə orta maşın dinləməli olduğu portda cavab verməyi dayandırır. İrəli tunel hələ də işləyir, uzaq host hələ də cavab verir və yalnız orta serverin özü xaricdən susur. Bu birləşmə məhz özünün yaratdığı bir hal olduğu üçün çaşdırıcıdır: orta keçid öz marşrut cədvəlinə tabe olur və cədvəl onun cavablarını yanlış tərəfə göndərir.
Orta qutu ilə danışana qədər işləyən zəncir
Nümunəvi bir zəncir götürün: A müştərisi B serverinə UDP 500 üzərindən çatır, B isə C serverinə UDP 500 üzərindən irəliləyir. C yalnız tək peer ünvanından trafik qəbul edir, bu da onu yarpaq edir və davranışını sadə saxlayır. B yarpaq deyil və bu nasazlıqla bağlı bütün maraqlı şeylər orada baş verir.
Bu fərq vacibdir, çünki yarpaq və orta rolları əks istiqamətlərə çəkir. Yarpaq hər şeyi bir tunelə nəticəsiz göndərə bilər, çünki heç nə ondan asılı deyil. Orta keçid eyni zamanda həm müştərilər üçün son nöqtə, həm də uzaq tərəfə doğru müştəridir və bu iki iş fərqli marşrutlaşdırma istəyir.
Cavab niyə tuneldən çıxır
B-də C-yə baxan interfeys AllowedIPs = 0.0.0.0/0 daşıyır, uyğun default marşrutla birlikdə. Buna görə B-nin yaratdığı hər paket, daha konkret bir şey üstünlük almadıqca, həmin tunelə daxil olur.
A-dan B-yə ünvanlanmış paket gəlir və qəbul edilir, çünki B təyinatdır və yerli çatdırılma əvvəl baş verir. Cavab A-nın ümumi ünvanına yönəlmiş tamamilə yeni, yerli yaradılmış paketdir və bu təyinat tunelin içindəki default marşruta uyğun gəlir. C onu alır, həmin ünvana sahib deyil və onu atır.
Simptom firewall problemi və ya açar uyğunsuzluğu kimi oxunur və burada heç biri doğru deyil. C-yə doğru tuneldə aparılan tutma cavabların yanlış istiqamətə getdiyini göstərir. Bu tək müşahidə hər hansı konfiqurasiya oxumaqdan daha çox vaxt qazandırır, ona görə açarları dəyişməyə başlamazdan əvvəl onu yazın. Tutmanı görməmiş hər kəs tunelin özünün pozulduğunu düşünəcək.
Dar təmir: mənbə portuna uyğun gələn siyasət qaydaları
B-nin dinləyən soketindən cavablar mənbə portu 500 ilə çıxır. Siyasət qaydası buna uyğun gələ və həmin paketləri adi cədvələ qaytara bilər:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Siyasət qaydaları prioritet sırası ilə nəzərdən keçirilir və əsas cədvəl 32766-da yerləşir, ona görə 100 səviyyəsindəki qayda tunelin default marşrutundan əvvəl soruşulur. Xaricdən əlçatan qalmalı hər port üçün bir giriş əlavə edin və artıq heç nə etməyin, belə ki yönləndirilən trafik qurulduğu tuneldən istifadə etməyə davam etsin.
Bu hiylənin sərhədini bilin. sport seçicisi yerli yaradılmış paketlərə uyğun gəlir, bu da məhz cavab halını əhatə edir və B-nin başqası üçün sadəcə yönləndirdiyi trafiki qəsdən əhatə etmir. B-nin arxasında yerləşdirilmiş xidmətin hələ də öz cavabına ehtiyacı var və bunun əksini iddia etmək birinci xidmət üçün işləyən, ikinci üçün isə uğursuz olan bir düzəliş yaradır.
Qaydaya bir sahib təyin edin
Promptda yazılan qayda interfeys növbəti dəfə yenidən qurulanda yox olur. WireGuard quraşdırmasında onu interfeysin yaradıldığı və silindiyi yerə qoyun:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Əgər interfeysə NetworkManager, distributiv çəngəli və ya konteyner giriş nöqtəsi sahibdirsə, bu cüt əl ilə redaktə edilən faylda deyil, həmin sahibdə olmalıdır. Effektiv qaydaları yenidən qoşulmadan sonra yoxlayın, yalnız ilk başlatmadan sonra deyil, çünki ilk başlatma həmişə işləyən haldır.
Alternativləri vicdanla müqayisə edin
Mənbə portu qaydası dörd çıxış yolundan biridir və onların ən darıdır. Onun tunel siyasətinə ümumiyyətlə toxunmamaq üstünlüyü var, buna görə sonrakı dəyişikliklərdən sonra da qalmağa meyllidir. Dar düzəlişlər tətbiq olunmağı dayandıranda uca səslə uğursuz olur, geniş istisna isə səbəbi yox olduqdan çox sonra da səssizcə işləməyə davam edir. İki il sonra qutunun sahibi başqası olanda bu fərq zəriflikdən daha çox önəm daşıyır.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
Seçdikdən sonra hər iki tərəfdən yoxlayın. A-dan B-nin portuna bağlantı başladın və bir müddət onu məşğul saxlayın. B-də nüvəyə cavab yolunu ip route get <address-of-A> sport 500 kimi bir şeylə əsaslandırın və onun tuneli deyil, WAN interfeysini adlandırdığını təsdiqləyin. Bundan sonra C-nin arxasındakı bir şeyin hələ də zəncir vasitəsilə cavab verdiyini yoxlayın, bu da istisnanın yan keçidə çevrilmək əvəzinə dar qaldığını sübut edir. Nəhayət, portları dizayn qeydlərinə yazın, əks halda növbəti operator bunu başqa xidmətdə yenidən kəşf edəcək.