Чаму прывілеяваны рэжым шырэйшы, чым патрэбна 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 і збой тунеля, перш чым назваць разгортванне завершаным. Дазвол на стварэнне інтэрфейсу не з’яўляецца палітыкай выхаду, і кантэйнер, які ідэальна тунелюе, усё роўна маршрутызуе ўсё, што адпраўляе праграма.