Korporativ VPN WireGuard daxilində: hansı qat əvvəl gəlir?

Tərtibatçının noutbukunda tunelləri iç-içə yerləşdirmək üçün iki haqlı səbəb var. Ya korporativ müştəri konkret bir ölkədən gəlirmiş kimi görünməlidir, ya da iki şəxsi şəbəkə eyni vaxtda əlçatan olmalıdır. Hər iki halda xarici tunel daxili müştərinin öz bağlantısını daşımalıdır.

İki müştərini hər hansı ardıcıllıqla başlatmaq bunu vermir. Bunu marşrutlaşdırma verir.

İki mümkün ardıcıllığı müqayisə edin

Xarici qatı son nöqtəsi açıq internetdən əlçatan olan tunel kimi seçin. Daxili qat isə serveri yalnız həmin çıxış vasitəsilə cavab verən tuneldir. Windows-da praktik bölgü budur: xaricdə WireGuard, daxildə korporativ müştəri. Həlledici amil nəzarətdir.

Rəsmi WireGuard müştərisi tam konfiqurasiya faylını tətbiq edir, marşrutlar və DNS daxil olmaqla. Kommersiya korporativ müştəriləri adətən hər ikisini gizlədir. Gizli müştərini xaricə qoymaq sizi altındakı yol barədə təxmin etməyə məcbur edir.

Əks ardıcıllıq qeyri-mümkün deyil. Sadəcə onu düşünmək daha çətindir, çünki xarici müştəri marşrutları heç vaxt görmədiyiniz bir cədvəl üzrə yenidən yazır.

Qoy AllowedIPs yalnız korporativ aralığı adlandırsın

AllowedIPs WireGuard-ın tunelə yönəltdiyi təyinatları sadalayır. İç-içə yerləşdirmə üçün ona yalnız daxili server ünvanı və korporativ prefikslər lazımdır. Qalan hər şey yerli şəbəkədə qalır, printerlər və hipervizar da daxil olmaqla. Bu, dizayn etibarilə bölünmüş tuneldir və istisna probleminin özündən tamamilə yayınır.

Tam tunelli xarici qat üçün lazımdır 0.0.0.0/0 çıxılmaqla yerli aralıqlar. Format istisnanı ifadə edə bilmir, buna görə tamamlayıcı hesablanıb yerinə yapışdırılmalıdır.

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

Daxili müştəri öz marşrutlarını quraşdırmadıqda, korporativ prefiksləri özünüz sadalayın. Həmin sətirdən kənarda qalan prefiks xarici tunelin heç vaxt daşımadığı təyinatdır. Siyahının köhnəlmiş nüsxəsi heç olmamasından pisdir, çünki yenə də düzgün görünür.

Ardıcıllıq, metrikalar və ikinci adapter

Əvvəlcə xarici tunelə qoşulun, sonra korporativ müştərini başladın. Onda onun son nöqtə bağlantısı yerli şlüz yerinə WireGuard-dan çıxır. Korporativ interfeysə daha aşağı metrika verin ki, onun prefiksləri sahib olduğu ünvanlar üzrə üstün gəlsin.

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

Metrikalar insanların atladığı addımdır. Sıralama olmadan üst-üstə düşən prefiks üzrə ən son quraşdırılmış marşrut qalib gəlir. Bu, hər açılışda dəyişir və problemin niyə fasiləli göründüyünün səbəbi budur.

OpenVPN 2.6 üzərində qurulmuş müştərilər öz tələlərini əlavə edir. Data kanalının boşaltma adapteri artıq məşğul olduqda, ikinci nüsxə sadəcə başlamaqdan imtina edir. Profilə disable-dco əlavə etmək köhnə TAP yoluna qayıdır və sonra hər ikisi yanaşı işləyir.

İç-içə yolun qırıldığı yer

Xarici tunelin bağlantısını kəsmək daxili tuneli öldürür. Yalnız daxili müştərini yenidən qoşmaq çox vaxt onu birbaşa internetə göndərir və iç-içəliyi sakitcə aradan qaldırır. Ardıcıllığı hər dəfə sıfırdan sınayın, hər iki tunel dayanmış vəziyyətdə başlayaraq.

Daha kiçik istifadə edilə bilən MTU gözləyin. Hər qat əlavə yük qatır, ona görə 1420 və 1400 ətrafında başlanğıc cütü başlamaq üçün yerdir. Böyük paketlərdə donan, kiçik sorğularda isə uğur qazanan ötürmə adi əlamətdir. Korporativ siyasət digər hədddir, çünki idarə olunan cihaz istəyən müştəri iç-içə yolu pozuntu hesab edə bilər.

Hər iki tərəf sabit şəbəkə olduqda, şlüzlər arasında sayt-sayt tuneli sıralama problemini idarə etmək yerinə aradan qaldırır. Bir noutbukda iki tunel yalnız o zaman birgə mövcud olur ki, hər birinin öz interfeysi və təyinatları prefiks üzrə seçən qaydası olsun.