VPN orqali Docker konteyneriga yetib bo‘lmayaptimi? Subnetlarni solishtiring

Konteynerlar ofis LAN tarmog‘ida javob beradi, keyin kompaniya VPN’i ulanagan paytda javob berishni to‘xtatadi. Konteynerda hech narsa o‘zgarmadi: qayta ishga tushirish yo‘q, obraz yangilanishi yo‘q, konfiguratsiya tahriri yo‘q. O‘zgargan narsa xostning marshrutlash jadvali, unda tunnel qo‘shgan marshrut endi Docker bergan manzilni qoplaydi. Subnetni tahrirlashdan yoki VPN istisnosini so‘rashdan oldin ikkala manzil rejasini yonma-yon qo‘ying, chunki tuzatishlar juda har xil vaqt oladi.

Konfiguratsiyani o‘zgartirishdan oldin marshrutni o‘qing

Docker haqiqatda qurgan tarmoqdan boshlang. IPAM bloki manzil rejasi, subnet esa muhim satr:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Compose sukut bo‘yicha har bir yangi loyihaga /16 ajratadi, shuning uchun ikki xizmat 65,536 manzil oralig‘ida joylashishi mumkin. Aynan shu kenglik tufayli ustma-ust tushishlar keng tarqalgan: tasodifiy tanlangan /16 tunnel orqali yetib boradigan saytni yutib yuborishga yetarlicha katta, va tunnel ko‘tarilmaguncha hech kim sezmaydi.

Keyin bitta konteyner manzili uchun marshrut tanlovini solishtiring — bir marta tunnel o‘chirilganda va bir marta yoqilganda:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

Javobning ikki shakli turli joylarga olib boradi. Agar chiqish tun0, wg0 yoki boshqa tunnel qurilmasini ko‘rsatsa, VPN prefiksi ko‘prik marshruti bilan kamida bir xil aniqlikka ega, va paket hech qachon konteynerga yetib bormaydi. Agar u hali ham ko‘prikni ko‘rsatsa, xost konteynerga yeta oladi, va sizning nosozligingiz filtrlash, DNS yoki faqat bir yo‘nalishda ishlamaydigan qaytish yo‘li.

/16 to‘qnashuvini urib yuborish nega oson

Docker ko‘prik tarmoqlarini xususiy hovuzlardan oladi, sukut hovuz esa 172.16.0.0/12 blokidan /16 bo‘laklari sifatida chiqadi. Korporativ tarmoqlar ko‘pincha o‘sha xususiy makondan foydalanadi, masofaviy VPN esa bu prefikslarni ulanadigan har bir mijozga suradi. Ikki tomon ham 172.18.0.0/16 o‘ziniki deb hisoblasa, bitta marshrutlash jadvalida ikkita qarama-qarshi da’vo bo‘ladi.

G‘olibni prefiks uzunligi hal qiladi, marshrutlar tartibi emas. 10.0.0.0/8 suradigan tunnel 172.18.0.0/16 ko‘prik marshrutini yengmaydi, chunki /8 kamroq aniq. 172.18.0.0/16 yoki uning ichidagi 172.18.5.0/24 ni suradigan tunnel yengadi. Shuning uchun bitta noutbuk ofis tarmog‘ida ishlaydi va o‘sha VPN bilan mehmonxona Wi-Fi’sida ishlamaydi: mijoz turli prefikslar oladi.

Xuddi shu jadval qarama-qarshi yo‘nalishni ham boshqaradi. 10.8.4.20 da ichki xost kerak bo‘lgan konteyner paketni o‘z ko‘prik shlyuziga yuboradi, keyin xost uni tunnelga yo‘naltiradi. Bu yo‘l odatda ishlaydi, chunki NAT ni xost bajaradi, lekin korporativ tomon faqat noutbukning VPN manzilini qabul qilsa yoki teskari yo‘l filtrlash assimetrik javobni tashlab yuborsa ishlamaydi.

Uchta tuzatishni solishtiring

Chiqish uchun faqat uch yo‘l bor, va ular kim tasdiqlashi hamda bittasini qo‘llayotganda nima buzilishi bilan farq qiladi.

Qayta raqamlash — chiptasiz tugatish mumkin bo‘lgan yagona tuzatish, shuning uchun ko‘p maqolalar shu joyda to‘xtaydi. Yosh loyihada bu arzon, migratsiya vositasi yoki saqlangan ulanish satri haqiqiy manzilga ishora qilgach esa qimmat bo‘ladi. Bu havolalarni YAML ni tahrirlashdan oldin sanang, keyin emas.

Ustma-ust tushish kompaniyangiz haqiqatan egalik qiladigan oraliqda bo‘lsa, tunneldan istisno eng toza javob. U ham eng sekin, va mijoz profilini o‘zgartira olmaydigan pudratchi uchun foydasiz. E’lon qilingan port yoki kichik teskari proksi bu bahsdan qochadi: mijoz tunnel allaqachon to‘g‘ri yo‘naltiradigan manzil bilan gaplashadi, va faqat shu port yetib borish mumkin bo‘lishi kerak.

Oraliqni ataylab belgilang

Bitta loyiha uchun, loyiha umumiy hovuzdan olmay qo‘yishi uchun compose faylida subnetni e’lon qiling:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

Bu oraliqni siz qidirayotganda topgan misoldan emas, jamoangiz yuritadigan reyestrdan oling. Uni VPN suradigan prefikslar, odamlar ishlaydigan uy LAN tarmoqlari va o‘sha xostdagi boshqa konteyner tarmoqlari bilan solishtirib tekshiring. Keyin qayta yaratishni rejalashtiring, chunki mavjud tarmoq eski subnetini saqlaydi: docker compose down, keyin up -d. docker network rm oxirgi nuqtalar ulangan bo‘lsa rad etadi, va fayldagi har qanday ipv4_address yozuvi yangi oraliqqa tushishi kerak.

Docker o‘zi yaratadigan tarmoqlar uchun /etc/docker/daemon.json da daemon hovuzini belgilang:

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

Hovuz daemon qayta ishga tushgandan keyin yaratilgan tarmoqlarga tegishli, allaqachon mavjud ko‘priklar esa manzillarini saqlaydi. Bu qulay va esdan chiqarish oson, shuning uchun kimdir uning tarmog‘ini qayta yaratmaguncha eski loyihani hali ham ustma-ust tushayotgan deb hisoblang. Docker’ning dvigatel tarmoq hujjati agar ko‘rikda hovuzni himoya qilish kerak bo‘lsa, taqsimlash qoidalarini tavsiflaydi.

Linux ko‘prigi va Docker Desktop turlicha ishlamaydi

Linux xostida konteynerlar xostning nomlar fazosidagi ko‘priklarda o‘tiradi. Hamma narsani bitta jadval hal qiladi, shuning uchun yuqoridagi solishtirish butun hikoya: ko‘prik marshrutini o‘qing, tunnel marshrutini o‘qing, va haqiqiy konteyner manzili uchun qaysi biri yutishini ko‘ring.

Docker Desktop konteynerlarni o‘z NAT’iga ega VM orqasiga qo‘yadi. Xostda konteyner manziliga umuman marshrut yo‘q; u xizmatga e’lon qilingan port orqali yetadi, odatda 127.0.0.1 ga bog‘langan. Shuning uchun VPN mijozi hech qanday subnet ustma-ust tushishisiz xizmatni buzishi mumkin: VM ning ichki oralig‘i uchun marshrut o‘rnatib yoki tunnel ulangan paytda loopback trafigini to‘sib. Agar xostda ip route get konteyner manzili uchun marshrut yo‘qligini xabar qilsa, bu kutilgan holat, xato emas.

Amaliy natija — siz birinchi navbatda qayerga qaraysiz. Linuxda marshrutlash jadvalidan boshlang. Desktopda e’lon qilingan port va VPN mijozining xavfsizlik devori qoidalaridan boshlang, keyin VM ning ichki subneti tunnel suradigan biror narsa bilan to‘qnashadimi-yo‘qmi tekshiring.

Tunnel yoqilganda tekshiring

Buni tuzatildi deb aytishdan oldin VPN ni ikki marta qayta ulang, chunki ulanishda marshrutlarni suradigan va uzilishda ularni qaytarib oladigan profil birinchi urinishdan keyin to‘g‘ri ko‘rinishi mumkin. Keyin mijoz haqiqatda bajaradigan tekshiruvlarni bajaring:

1. Konteynerning haqiqiy manzilidan foydalanib xostdan ip route get.
2. Xizmatning o‘zi sog‘lomligini isbotlash uchun boshqa konteynerdan so‘rov.
3. Tunnel yoqilganda mijozdan curl -sv http://127.0.0.1:8080/, keyin LAN dagi mashinadan konteyner manziliga traceroute -n.
4. So‘rov xostga yetib borsa-yu javob yo‘qolsa, sysctl net.ipv4.conf.all.rp_filter.

Nihoyat, tanlangan oraliqni uni tanlashda ishlatgan reyestrga sana va unga egalik qiladigan loyiha bilan birga yozing. Keyingi ustma-ust tushish hech kim hujjatlashtirmagan loyihadan keladi, va yagona himoya — oraliq tasodifiy olinmagani, ataylab band qilingani.