Зашто Docker контејнер не стиже до хостова иза VPN-а

Контејнер који не стиже ни до чега иза корпоративног VPN-а обично живи у другом мрежном простору имена од тунела. Руте, DNS сервери и ознаке заштитног зида клијента хоста припадају стек-у хоста; контејнер на мост мрежи има свој. Та једна чињеница објашњава већину пријава које стижу до платформ тима, и она је и разлог зашто „VPN је покварен“ и „Docker заобилази VPN“ могу бити нетачни истовремено. Две веома различите поставке крију се иза једног симптома, зато утврдите коју имате пре него што промените било које подешавање.

Утврдите чији простор имена поседује тунел

На Docker Desktop-у за macOS или Windows контејнери раде унутар Linux виртуелне машине. VPN клијент инсталиран на радној површини ствара тунел у оперативном систему радне површине, а виртуелна машина га никада не види. Ниједна конфигурација контејнера то не поправља, јер интерфејс који би контејнеру требао уопште не постоји у његовом мрежном простору имена.

На Linux хосту тунел живи у простору имена хоста, а мост контејнери обично стижу до њега кроз табелу рутирања хоста са NAT-ом извора примењеним на излазу. Када тај пут закаже, узрок је обично политика прослеђивања, филтрирање повратног пута или подмрежа која се преклапа, а не рута која недостаје. Потврдите у ком од два света сте пре него што наставите да читате:

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

Разлика између те две табеле рутирања је цео проблем на једном екрану. Ако приказ хоста садржи интерфејс тунела, а приказ моста не, гледате изолацију простора имена, и све остало је избор како је прећи.

Мрежа хоста је тест, а не пројекат

Покретање контејнера са мрежом хоста, што Docker документује као дељење мрежног простора имена хоста, чини да директно наследи интерфејс тунела и његове руте. Ако исти захтев затим успе, теорија рута је потврђена и квар је изолација простора имена, а не акредитиви, DNS или правило приступа.

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

Задржите то као дијагностику. Мрежа хоста се одриче објављивања портова и већине изолације коју сте желели од контејнера, а на Docker Desktop-у „host“ значи виртуелну машину, не радну површину, па вас успех или неуспех тамо може завести ако заборавите ком хосту сте се обраћали.

tun уређај и привилегије које долазе с њим

VPN клијенту унутар контејнера потребан је тунелски уређај и дозвола да га конфигурише. Уобичајена кратица је --privileged, која даје сваки уређај и олабављује безбедносну политику у целом контејнеру. То је далеко више него што овај задатак захтева и тешко се оправдава на прегледу.

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

Ужа форма мапира један чвор уређаја и додаје само могућност мрежне администрације. Прво учитајте модул на хосту да би чвор постојао. Ако контејнер крене, а клијент пријави да не може да отвори тунелски уређај, проверите мапирање пре него што посумњате у профил, јер је та грешка обично дословна.

Овај дизајн такође значи да клијент ради за сваки контејнер. То је тачан одговор када свако радно оптерећење треба сопствени тунел, а погрешан када сте само желели да тунел хоста буде видљив, што је платформ тим вероватно претпоставио да радите.

NAT моста мења извор који VPN види

Са подразумеваним мостом, излазни саобраћај контејнера преводи се на адресу хоста. Зато иза VPN-а корпоративна страна види адресу тунела хоста, а не контејнера, правила приступа по извору понашају се као да је захтев послао хост, и два контејнера постају неразлучива VPN серверу.

macvlan или ipvlan уместо тога даје контејнеру LAN адресу, што помаже откривању на LAN-у и чини да контејнер изгледа као равноправни на сегменту. Такође потпуно заобилази тунел хоста, па такав контејнер неће стићи до префикса само за VPN, осим ако је VPN доступан и из тог LAN-а.

Обе форме су легитимне; оне одговарају на различите захтеве. Ако је захтев „овај контејнер мора да стигне до услуге само за VPN“, бирате између рутирања кроз хост и завршавања тунела унутар контејнера. Запишите тај избор пре увођења, а не после првог неуспелог захтева. Шта год да изаберете, забележите адресу извора коју ће видети удаљена страна, јер ће управо то показати њена правила приступа и њени дневници. Дизајн који не може да наведе ту адресу није завршен.

DNS прати демона, а не тунел

Контејнер добија конфигурацију резолвера при покретању, копирану из демона или из слике. Адресе које VPN гурне после повезивања стижу прекасно за ту копију и гурају се у резолвер хоста, а не у контејнер.

Подесите резолвер експлицитно за услугу или га усмерите на интерни резолвер доступан кроз тунел. Контејнер који приватно име решава у јавну адресу обично користи јавни резолвер, не пати од покварене руте, а исправка припада compose датотеци или конфигурацији демона.

Исто размишљање важи и за питање излазне адресе. Ако сваки контејнер мора да се појави са различите VPN адресе, један тунел хоста то не може да обезбеди јер их NAT сажима у један извор. Изводљиве форме су клијент у простору имена сваког контејнера или sidecar који поседује тунел и дели свој стек, и обе мењају како се апликација адресира.

Контролна листа пре затварања тикета: утврдите простор имена који поседује тунел, докажите пут мрежом хоста, мапирајте само потребан tun уређај, запамтите адресу извора после NAT-а, подесите резолвер експлицитно и третирајте излазне адресе по контејнеру као архитектонску одлуку, а не као заставицу.