Зошто привилегираниот режим е поширок од она што му треба на VPN

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

Што всушност менува знаменцето

Привилегиран контејнер добива широки можности и пристап до уредите на домаќинот, што е многу поголема дозвола отколку што бара мрежната патека. Точниот збир го документира извршната околина, а не го одредува преданието, и документацијата на Docker за извршување контејнери ги опишува достапните опции за привилегии. Едно читање е доволно за да се види дека тунелот е мал дел од целината.

Два потесни барања покриваат повеќето VPN контејнери. Конфигурирањето интерфејс бара можност за мрежна администрација, а отворањето на тунелскиот уред бара пристап до точно тој јазол на уредот. Тоа се одделни дозволи, и дури и двете заедно се потесни од општата опција. Остатокот од привилегираниот збир нема никаква врска со тунелот. Тој постои за работни оптоварувања на кои навистина им треба пристап на ниво на домаќин, а VPN контејнерот обично не е еден од нив.

Поврзете ја секоја грешка со еден предуслов

Пораката за грешка ви кажува кој предуслов недостасува ако ја прочитате пред да ја потиснете. Порака за јазол на уред го именува уредот, порака за недозволена операција именува можност, а порака за модул или sysctl именува поддршка на јадрото. Секоја од нив има различно решение, и само една од нив е можност.

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

Проверете го предусловот, не симптомот

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

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

Контејнер што го гледа уредот и ја има можноста, но и понатаму не успева, ви кажува дека проблемот е на друго место. Тоа е корисен резултат, а привилегираниот режим би го скрил.

Проверете ги и дозволите на уредот на домаќинот, бидејќи правилно доделен јазол на уред со погрешно групно сопственост го дава истиот проблем како дозвола што недостасува.

Запишете ја најтесната дозвола што работи

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

Прегледајте го и околниот контекст, бидејќи мрежата на домаќинот, поврзувањата на домаќинот и опциите на извршната околина секоја може да го прошири влијанието на дозволата. Изолираниот лабораториски повик што ги комбинира сите не е производна конфигурација, колку и добро да работел. Тестирајте ја апликацијата, нејзиното однесување во DNS и неуспехот на тунелот пред да го прогласите распоредувањето за завршено. Дозволата да создадете интерфејс не е политика за излез, а контејнер што совршено тунелира с уште го насочува сето она што апликацијата го испраќа.