Слике контејнера могу да носе све потребне OpenVPN бинарне и конфигурационе датотеке и ипак не успеју на првом мрежном позиву. Грешка именује /dev/net/tun јер је апликација затражила од језгра TUN интерфејс, а контејнер није имао ни чвор уређаја ни способност да га створи. То су два одвојена дозвола, а поправка једног оставља други тачно тамо где је био.

Њихово раздвајање захтева по једну команду за сваки. Порука о грешци после тога вам каже на којој сте граници заправо стајали.

Чвор уређаја и способност су двоја врата

Чвор уређаја је објекат датотечног система, па га контејнер мора видети у свом сопственом простору имена за монтирање. Способност је дозвола, па процес треба CAP_NET_ADMIN у простору имена где ће интерфејс бити створен. Преношење уређаја без способности даје вам чвор који се отвара и ioctl који не успева. Давање способности без уређаја оставља апликацију неспособном да отвори било шта, због чега се обоје обично појављује заједно у примерима.

Поставка devices у Docker-у мапира уређај домаћина у контејнер, док cap_add прилагођава скуп способности. Bind mount исте путање ставља датотеку у видокруг без примене семантике приступа уређају.

Репродукујте то изван Compose датотеке

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

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

Недостатак чвора на домаћину значи да модул tun није доступан, што је поправка на страни домаћина, а не контејнера. Чвор који постоји али се не може отворити у контејнеру упућује на приступ уређају, а порука ће рећи permission denied уместо no such file. Редослед те две грешке је цела дијагноза. Запишите коју сте видели пре него што промените заставицу.

Грешке после TUN-а су различити проблеми

Чим се интерфејс појави, следећи неуспех има другог власника. Грешке аутентификације значе да је тунел стигао до сервера и да су акредитиви одбијени, па промене способности неће помоћи. Тунел који се успостави док апликације и даље не успевају упућује на руте, прослеђивање, DNS резолуцију унутар контејнера или сопствени мрежни распоред контејнера. Свака од њих је обично мрежно питање на које дозвола за TUN не може да одговори. Понављање првобитног теста после сваке измене спречава да се неуспеси слеју у један утисак.

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

Проверите интерфејс унутар контејнера

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

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

Способност присутна у bounding set али одсутна из effective set понаша се другачије од оне која никада није додељена, а capsh приказује обе. Ако чвор постоји и способност је ту док стварање и даље не успева, окружење за извршавање намеће нешто друго, попут seccomp профила или AppArmor политике која ограничава операцију. То је трећа граница, документована од окружења за извршавање, а не од апликације.

Запишите заставице контејнера, слику и тачну грешку сваког покушаја. Следећа особа која прочита ту белешку моћи ће да каже која су врата била затворена без понављања целе истраге.

Повезани чланци