İki iç-içə tunel sizi anonim etmir. Onlar müşahidələri iki provayder arasında bölür, yəni heç biri ev ünvanınızı və təyinatınızı birlikdə görmür. Bu, həqiqi, lakin dar bir faydadır və ondan ilk dəfə asılı qaldığınızda ortaya çıxan marşrutlaşdırma, DNS və MTU problemləri ilə gəlir.

1. İkinci hoppun nə üçün olduğunu qərarlaşdırın

Heç nə konfiqurasiya etməzdən əvvəl məqsədi bir cümlə ilə yazın. Məqsəd provayderinizin hansı saytlara girdiyinizi görməməsidirsə, bir tunel bunu təmin edir. Məqsəd heç bir tək provayderin ünvanınızı trafikinizlə əlaqələndirə bilməməsidirsə, iki tunel bunu edir. Məqsəd sizi heç kimin müəyyən edə bilməməsidirsə, heç bir hopp sayı buna çatmır.

Zəncir yalnız zəif provayderin logları və hər ikisinin saxladığı hesab qeydləri qədər güclüdür. Ödənişlər, qeydiyyat e-poçtu və tətbiq telemetriyası tunelin tamamilə xaricindədir.

2. Daxili ucu xarici tunel vasitəsilə əlçatan edin

Adi uğursuzluq daxili tunelin heç vaxt qurulmamasıdır. Tam tunel xarici bağlantı standart marşruta sahibdir, ona görə daxili müştərinin öz ucuna çatmaq cəhdi xarici tunel tərəfindən udulur və atılır ya da döngüyə düşür. Daxili uc xarici interfeysdən açıq marşrut tələb edir və bu, daxili müştəri başlamazdan əvvəl quraşdırılmalıdır. Əks halda əl sıxma marşrutla yarışır və uduzur.

WireGuard eyni konflikti digər tərəfdən göstərir. Hər peer-in AllowedIPs sahəsi hansı təyinatların o tunelə girdiyini müəyyən edir, buna görə hər ünvanı iddia edən daxili interfeys daha dəqiq marşrut qalib gəlməzsə, xarici ucu da iddia edir. İki interfeysdə üst-üstə düşən AllowedIPs isə bir tərəfin səssizcə uduzduğu konfiqurasiyadır.

Konteyner zəncirləmə ayırmanı açıq, tələni isə aşkar edir. Öz ad məkanı, öz standart marşrutu və içində müştərisi olan konteyner hostun ona göndərdiklərini ötürür; host özü həmin yoldan istifadə etməyə başlamır. Forwardinqi aktivləşdirin, konteynerin tuneli üçün marşrut əlavə edin və xidməti konteyner ünvanına yönəldin.

3. DNS-i eyni yolda saxlayın

DNS trafikin getdiyi yerdən getməlidir. Daxili provayder resolverləri təqdim edirsə və host hələ də yerli olanları soruşursa, bu sorğular tunelin gizlətməli olduğu saytları məhz açıq edir. Müştərinin status paneline güvənmək əvəzinə hər tunel interfeysində ələ keçirmə ilə yoxlayın. Buradakı sızma normal gəzinti zamanı görünməz, ələ keçirmədə isə aşkardır.

Bölünmüş DNS dizaynları bunu çətinləşdirir, çünki yerli ad üçün sorğu qanuni olaraq tuneldən kənara aid ola bilər. İstisna siyahısını hansı resolverin cavab verdiyindən asılı olaraq kəşf etmək əvəzinə qəsdən yazın.

4. MTU-nu istifadəçilər sizin üçün kəşf etməzdən əvvəl təyin edin

MTU digər proqnozlaşdırıla bilən itkidir. İki inkapsulyasiya iki başlıq çıxarır, yol MTU-sunu artıq aşağı salmış xarici tunel isə içəridə daha az yer qoyur. Simptomlar tanışdır: kiçik sorğular keçir, böyük ötürmələr və TLS əl sıxmaları dayanır.

ip link set dev wg1 mtu 1280 kobud həlldir, forwarderdə MSS sıxmaq isə daha səliqəli yoldur. Bağlantını yenidən cəhd etmək heç bir həll deyil.

5. Həqiqətən alacağınız uğursuzluğu sınaqdan keçirin

Xarici tuneli qəsdən qırın və nə baş verdiyinə baxın. Xarici hopp öləndə səssizcə birbaşa yola qayıdan zəncir zəncirsizlikdən pisdir, çünki tam sizin qorunduğunuza inandığınız anda sızır. Hədəf davranış bütün trafiki dayandıran kill switch-dir. Nəticəni qeyd edin, çünki hadisənin ortasında onu yenidən kəşf etmək istəməyəcəksiniz.

Gecikmə və ikinci uğursuzluq nöqtəsi daimi xərclərdir. İki hopp həm də əlverişsiz saatda nəsə pozulanda iki dəstək növbəsi deməkdir.

Əlaqəli məqalələr