Docker konteyneri VPN arxasındakı hostlara niyə çata bilmir

Korporativ VPN-in arxasındakı heç bir şeyə çata bilməyən konteyner adətən tuneldən fərqli şəbəkə ad sahəsində yaşayır. Host müştərisinin marşrutları, DNS serverləri və firewall işarələri host yığınına aiddir; körpü şəbəkəli konteynerin isə öz yığını var. Bu tək fakt platforma komandasına çatan hesabatların çoxunu izah edir və həm də «VPN xarab olub» ilə «Docker VPN-i yan keçir» ifadələrinin eyni vaxtda səhv ola bilməsinin səbəbidir. Bir əlamətin arxasında iki tamamilə fərqli quruluş gizlənir, ona görə hər hansı ayarı dəyişməzdən əvvəl hansına sahib olduğunuzu müəyyənləşdirin.

Tunelin kimin ad sahəsinə aid olduğunu müəyyənləşdirin

macOS və ya Windows üçün Docker Desktop-da konteynerlər Linux virtual maşınının içində işləyir. Masaüstündə quraşdırılmış VPN müştərisi masaüstü əməliyyat sistemində tunel yaradır və virtual maşın bunu heç vaxt görmür. Heç bir konteyner konfiqurasiyası bunu düzəltmir, çünki konteynerin ehtiyac duyduğu interfeys onun şəbəkə ad sahəsində ümumiyyətlə yoxdur.

Linux hostunda tunel host ad sahəsində yaşayır və körpü konteynerləri ona adətən host marşrut cədvəli vasitəsilə, çıxışda mənbə NAT-ı tətbiq olunmaqla çatır. Bu yol sıradan çıxdıqda səbəb adətən çatışmayan marşrut deyil, yönləndirmə siyasəti, tərs yol filtrasiyası və ya üst-üstə düşən subnet olur. Daha uzağa oxumazdan əvvəl iki dünyadan hansında olduğunuzu təsdiqləyin:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

Bu iki marşrut cədvəli arasındakı fərq bütün problemi bir ekranda göstərir. Host görünüşündə tunel interfeysi varsa, körpü görünüşündə isə yoxdursa, siz ad sahəsi təcridinə baxırsınız və qalan hər şey onu necə keçmək seçimidir.

Host şəbəkəsi sınaqdır, dizayn deyil

Konteyneri host şəbəkəsi ilə işlətmək — Docker bunu host şəbəkə ad sahəsinin paylaşılması kimi sənədləşdirir — ona tunel interfeysini və marşrutlarını birbaşa miras verir. Əgər eyni sorğu bundan sonra uğurlu olarsa, marşrut nəzəriyyəsi təsdiqlənir və nasazlıq etimad məlumatları, DNS və ya giriş qaydası deyil, ad sahəsi təcrididir.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

Bunu diaqnostik vasitə kimi saxlayın. Host şəbəkəsi port yayımından və konteynerdən istədiyiniz təcridin çoxundan imtina edir, Docker Desktop-da isə «host» masaüstü deyil, virtual maşın deməkdir, ona görə hansı hosta müraciət etdiyinizi unutsanız, oradakı uğur və ya nasazlıq sizi çaşdıra bilər.

tun cihazı və onunla gələn imtiyazlar

Konteynerin içindəki VPN müştərisinə tunel cihazı və onu konfiqurasiya etmək icazəsi lazımdır. Ümumi qısa yol --privileged bayrağıdır ki, bu, bütün cihazları verir və konteyner üzrə təhlükəsizlik siyasətini yumşaldır. Bu, bu işin tələb etdiyindən qat-qat artıqdır və rəydə əsaslandırmaq çətindir.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

Daha dar forma tək cihaz düyününü xəritələyir və yalnız şəbəkə idarəetmə imkanını əlavə edir. Düyün mövcud olsun deyə əvvəlcə modulu hostda yükləyin. Konteyner başlayır və müştəri tunel cihazını aça bilmədiyini bildirirsə, profildən şübhələnməzdən əvvəl xəritələməni yoxlayın, çünki bu xəta adətən hərfi mənadadır.

Bu dizayn həm də müştərinin hər konteyner üçün işləməsi deməkdir. Hər iş yükü öz tunelinə ehtiyac duyduqda bu düzgün cavabdır, sadəcə host tunelinin görünməsini istədiyiniz halda isə səhv cavabdır — platforma komandası çox güman ki, sizin bunu etdiyinizi güman edirdi.

Körpü NAT-ı VPN-in gördüyü mənbəyi dəyişir

Standart körpüdə konteynerin çıxan trafiki host ünvanına çevrilir. Buna görə VPN arxasında korporativ tərəf konteynerin deyil, hostun tunel ünvanını görür, mənbə üzrə giriş qaydaları sanki sorğunu host edib kimi davranır və iki konteyner VPN serveri üçün fərqlənməz olur.

macvlan və ya ipvlan konteynerə bunun əvəzinə LAN ünvanı verir, bu da LAN kəşfinə kömək edir və konteyneri seqmentdə həmkar kimi göstərir. O, həm də host tunelini tamamilə yan keçir, ona görə belə konteyner VPN həmin LAN-dan da əlçatan deyilsə, yalnız-VPN prefikslərinə çatmayacaq.

Hər iki forma qanunidir; onlar fərqli tələblərə cavab verir. Tələb «bu konteyner yalnız-VPN xidmətinə çatmalıdır»dırsa, siz host vasitəsilə marşrutlaşdırma ilə tuneli konteynerin içində sonlandırma arasında seçim edirsiniz. Bu seçimi yerləşdirmədən əvvəl yazın, ilk uğursuz sorğudan sonra yox. Hansını seçsəniz seçin, uzaq tərəfin görəcəyi mənbə ünvanını qeyd edin, çünki onun giriş qaydaları və jurnalları məhz bunu göstərəcək. Bu ünvanı deyə bilməyən dizayn bitmiş sayılmır.

DNS tunelə deyil, daemon-a uyğun gəlir

Konteyner başlayanda öz resolver konfiqurasiyasını alır, o, daemon-dan və ya imicdən kopyalanır. VPN-in qoşulduqdan sonra göndərdiyi ünvanlar bu kopya üçün çox gec gəlir və onlar konteynerə deyil, host resolverinə göndərilir.

Resolveri xidmət üçün açıq şəkildə təyin edin və ya onu tunel vasitəsilə əlçatan daxili resolverə yönəldin. Şəxsi adı ictimai ünvana həll edən konteyner adətən pozulmuş marşrutdan deyil, ictimai resolverdən istifadə edir və düzəliş compose faylına və ya daemon konfiqurasiyasına aiddir.

Eyni məntiq çıxış ünvanı sualına da aiddir. Hər konteyner fərqli VPN ünvanından görünməlidirsə, bir host tuneli bunu verə bilməz, çünki NAT onları bir mənbədə birləşdirir. İşlək formalar hər konteynerin ad sahəsində müştəri və ya tunelə sahib olub yığınını paylaşan sidecar-dır və hər ikisi tətbiqin ünvanlanmasını dəyişir.

Bileti bağlamazdan əvvəl yoxlama siyahısı: tunelə sahib ad sahəsini müəyyən edin, yolu host şəbəkəsi ilə sübut edin, yalnız lazım olan tun cihazını xəritələyin, NAT-dan sonra mənbə ünvanını unutmayın, resolveri açıq təyin edin və konteyner üzrə çıxış ünvanlarını bayraq deyil, arxitektura qərarı kimi qəbul edin.