OpenVPN arxasında Docker və VM trafiki: marşrutlaşdırma, yoxsa yenidən nömrələmə?

Host tuneldən istifadə edərək gəzir, yanındakı konteyner isə heç nəyə çatmır. Öz VPN müştərisi olan konteynerdən port dərc etmək daha pisdir: sorğu gəlir, cavab isə heç vaxt çıxmır. Hər ikisi hostdakı marşrut qərarıdır və Docker yalnız xəbərçidir.

Üç sual hansı iki halın qarşısında olduğunuzu müəyyən edir və təxminən bir dəqiqə çəkir.

Eyni görünən iki nasazlıq

Birincisi geri yol probleminə aiddir. Dərc edilmiş port konteynerə çevrilir, sorğu gəlir və cavab hostun standart marşrutu ilə yönləndirilir; OpenVPN müştərisi bu marşrutu tun0-a yönəldib. Cavab uzaq həminin gözləmədiyi ünvandan çıxır və atılır. İkincisi prefiks toqquşmasıdır: Docker-in standart körpüsü 172.17.0.0/16 ünvanına sahibdir və korporativ tunel eyni diapazonu təqdim edir.

Biri marşrut cədvəli ilə, digəri körpünü yenidən nömrələməklə düzəldilir. Hansının hansı olduğunu bilməzdən əvvəl redaktə etmək işləyən konteyneri məhv etməyin yoludur.

Üç sualla qərar verin

Birinci sual: VPN-i dayandırdıqda nasazlıq yox olurmu? Tunel söndürülmüş halda hər şey işləyirsə, geri yoldan şübhələnin. İkinci sual: ip route show table all eyni prefiksi iki dəfə göstərirmi, bir dəfə körpüdə və bir dəfə tun0-da? Bu, toqquşmadır. Üçüncü sual: təsirlənən ünvan konteynerdir, NAT qonağıdır, yoxsa körpüyə qoşulmuş qonaqdır?

Üçüncü sual vacibdir, çünki hər birinin fərqli düzgün həlli var və konteyner həllini libvirt qonağına tətbiq etmək bir axşamı boşa verir.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Geri yol: bir mənbə ünvanı üçün cədvəl

Konteynerin trafiki fiziki interfeysdən çıxmalı, host isə tuneldən istifadə etdikdə, ən kiçik dəyişiklik mənbəyə əsaslanan marşrutlaşdırma olur. Konteynerin ünvanına uyğun qayda əlavə edin və onu ayrı cədvələ göndərin. Hostda başqa heç nə yerindən tərpənmir.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Mənbəyi həmin ünvan olan hər paket ilk növbədə 10-cu cədvələ baxır və 10-cu cədvəl onu tunelə deyil, körpü şlüzünə göndərir.

Bunu şununla təsdiqləyin: ip route get 1.1.1.1 from 172.22.0.3. Cavab körpü interfeysini adlandırmalıdır, tun0-u yox. Bu şəkildə əlavə edilən qaydalar yenidən başlatmada itir, ona görə onları konteynerə sahib olan unit və ya şəbəkə qarmağına yazın.

Eyni naxış cavab yolu da açıq qayda tələb edən WireGuard konteyneri üçün də işləyir.

Prefiks toqquşması: körpünü yenidən nömrələyin

Marşrut cədvəli bir prefiksi bir yerə göndərir. VPN 172.17.0.0/16-nı təqdim edir və Docker-in körpüsü artıq oradadırsa, aşağı metrika qazanır: Docker qoşulmuş marşrutunu 0 metrikanı ilə quraşdırır, təqdim edilən marşrut 50 metrikanı ilə gəlir. Sonra Docker işləməyə davam edərkən tunel pozulmuş görünür və ya əksi, quraşdırma sırasından asılı olaraq. Metrika ilə mübarizə aparmaq əvəzinə körpünü yenidən nömrələyin.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

Dəyişiklikdən sonra Docker-i yenidən başladın və köhnə hovuzla qurulmuş şəbəkələri yenidən yaradın. Əvəzində metrikanı dəyişmək yalnız konflikti növbəti açılışa köçürür.

VM-lər yenə başqa cavab tələb edir

Standart NAT şəbəkəsindəki libvirt qonağı hostun marşrutlaşdırmasını miras alır və host tuneli standart marşruta sahib olduqdan sonra xaricə çıxışı dayanır. Qonağı körpülü və ya macvtap cihazına keçirmək ona fiziki şəbəkədə öz yolunu verir. virt-manager-də avadanlıq əlavə edin, Network seçin, mənbəyi macvtap host cihazına qoyun, model olaraq virtio saxlayın, sonra köhnə NAT interfeysini söndürün.

macvtap qonağı adətən öz hostuna çata bilmir. Bu, nasazlıq deyil, gözlənilən davranışdır və arxada qoyduğunuz qeydə daxil edilməlidir.

Yalnız hostun LAN-ına ehtiyacı olan qonaq üçün satıcı müştərisində çatışmayan açar ola bilər: Mullvad ilə mullvad lan set allow libvirt-ə toxunmadan yerli əlçatanlığı bərpa edir. Konteyner yalnız tunel vasitəsilə əlçatan olmalıdırsa, dərc edilmiş portu tunel ünvanına bağlayın, -p 10.8.0.5:8080:8080, hər ünvanda dərc etmək əvəzinə.