Niyə macvlan konteyneri VPN müştərisinə cavab verə bilmir

VPN-i sonlandıran və eyni zamanda macvlan şəbəkəsində konteyner işlədən Linux hostunu təsəvvür edin. LAN 192.168.60.0/24-dir, konteyner 192.168.60.210 ünvanını tutur, VPN müştəriləri isə 10.95.0.0/24-dən gəlir. Müştəri xidmətə çatır, cavab heç vaxt qayıtmır və hostdakı hər firewall qaydası düzgün görünür. Bu simptomu iki ayrı məhdudiyyət yaradır və onlardan birini düzəltmək digərini yerində saxlayır.

İki məhdudiyyət, bir simptom

Birinci məhdudiyyət təcriddir: Docker-in macvlan sürücüsü konteynerə valideyn interfeysi vasitəsilə öz hostu ilə danışmağa imkan vermir. Host yığını ilə konteyner arasındakı trafikin heç bir yolu yoxdur, hostdakı marşrutlar necə yazılsa da.

İkinci məhdudiyyət geri dönüş yoludur. Konteynerin standart şlüzü adətən LAN marşrutlaşdırıcısıdır, buna görə VPN müştərisinə ünvanlanmış cavab həmin marşrutlaşdırıcıdan çıxır. Əgər marşrutlaşdırıcının VPN hovuzuna geri marşrutu yoxdursa, cavab haradasa ortada atılır.

Bu iki nasazlıq müştəri baxımından eyni görünür: gələn sorğu və heç vaxt gəlməyən cavab. Onlar fərqli təmir tələb edir və geniş masquerade qaydası hansının hələ də xarab olduğunu gizlədə bilər. Buna görə ilk sınaq başqa bir firewall dəyişikliyi deyil, konteyner tərəfində tutulan paket çıxarışıdır. Əgər sorğu orada heç görünmürsə, o zaman təcrid məhdudiyyəti işdədir.

Host tərəfində keçidi dar şəkildə qurun

Hostda eyni valideynə körpü rejimində qoşulmuş ikinci macvlan interfeysi host yığınına həmin LAN seqmentində öz kimliyini verir. Onun üçün DHCP hovuzundan və konteyner diapazonundan kənarda ünvan ayırın və yalnız konteyneri onun vasitəsilə yönləndirin.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Birinci əmr interfeysi körpü rejimində yaradır, bu da bu sürücü üçün sənədləşdirilmiş standartdır və host-konteyner trafiki üçün istədiyiniz rejimdir. İkincisi /32 təyin edir ki, ünvan LAN prefiksi ilə toqquşmasın, dördüncüsü isə yalnız konteynerin ünvanını keçid vasitəsilə göndərir.

Bütün LAN-ı yeni interfeys vasitəsilə yönləndirməyin. Adi qoşulmuş marşrut olduğu kimi qalır və host marşrutu qəsdən dardır ki, bir konteyner yol qazansın, seqmentin qalan hissəsi isə davranışını dəyişməsin. Keçidə yönəlmiş standart marşrut fərqli nəticələri olan fərqli bir dizayn olardı. Onu konkret saxlayın, təsir dairəsi kiçik qalsın.

Bu əmrlər işlək hostda şəbəkə parametrlərini dəyişir. Cihazda və ya idarə olunan platformada həmin platformanın dəstəklənən konfiqurasiya mexanizmindən istifadə edin, çünki interaktiv root-shell dəyişikliyi yeniləmədən sonra qalmaya bilər.

Mənbənin necə saxlanacağına qərar verin

Keçid yerində olduqda konteyner hosta çata bilir və sual cavabın hansı mənbə ünvanını daşıdığına çevrilir. Orijinal VPN mənbəyini saxlamaq daha təmiz modeldir: konteyner real müştəri ünvanını görür və xidmətin jurnalları ilə giriş qaydaları ondan istifadə edə bilər.

Bunun işləməsi üçün konteynerin şəbəkə konfiqurasiyası bu yol üçün 10.95.0.0/24 trafikini şlüz kimi 192.168.60.250-ə göndərməlidir. Bu, konteynerin öz konfiqurasiyası daxilində dəstəklənən marşrut və ya şlüz parametridir, host tərəfində bir hiylə deyil. Parametrin qüvvəyə mindiyini fərz etmək əvəzinə konteynerin içindən təsdiqləyin. Hələ də LAN marşrutlaşdırıcısına baxan standart şlüz cavabları eyni dəliyə göndərməyə davam edəcək.

Əgər təsdiqlənmiş dizayn əvəzində VPN mənbələrini gizlədirsə, çevirməni dar qurun: real VPN hovuzu, çıxış interfeysi kimi keçid və konkret konteyner və xidmət.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Keçidi çıxış interfeysi kimi uyğunlaşdırın, tuneli deyil. Tuneli çıxış interfeysi adlandıran qayda konteynerə doğru gedən paketə uyğun gəlməyəcək və bu cür quruluşların adətən saxladığı səhv məhz budur. Qaydanı yuxarıdakı cümlə qədər dar saxlayın və hovuz dəyişdikdə yenidən nəzərdən keçirin.

Hostdan deyil, müştəridən yoxlayın

Hostun özündən keçid ünvanına bağlanmış sorğu keçidin konteynerə çata bildiyini sübut edir. Bu, konteynerin saxlanmış 10.95.0.x mənbəyinə trafik qaytara bildiyini sübut etmir, çünki həmin sınaqda mənbə ünvanı keçidin öz ünvanıdır.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

Birinci əmr hostdan konteynerə qolu sınaqdan keçirir, ikincisi isə real VPN müştərisi sorğu göndərərkən keçiddən həqiqətən nə keçdiyini göstərir. Giriş yolundakı mənbə ünvanına və eyni axınla cavabın görünüb-görünmədiyinə baxın.

Hostda yönləndirmə aktiv olmalıdır və yönləndirmə yoluna VPN hovuzundan keçidə xidmət portu üzrə icazə, üstəlik qurulmuş cavablar üçün icazə lazımdır. Hostdakı INPUT qaydası yönləndirilən trafikə icazə vermir və bu, marşrutlaşdırma düzgün göründükdən sonra paketin atılmasının geniş yayılmış səbəbidir.

Real proqramı real etimad məlumatları ilə işə salın, sonra eyni konteynerdəki ikinci, əlaqəsiz xidmətin sizi hələ də rədd etdiyini yoxlayın. Əgər işləməsinin yeganə yolu bütün yönləndirmə qaydalarını açmaq idisə, dizayn tamamlanmayıb. Xidmətin hansı mənbə ünvanını qeyd etdiyini də qeyd edin, çünki bundan sonra onun öz giriş qaydaları ondan istifadə edəcək.