Зошто 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, поставете го резолверот експлицитно и третирајте ги излезните адреси по контејнер како архитектонска одлука, а не како знаменце.