კონტეინერის იმიჯებს შეუძლიათ ატარონ ყველა საჭირო OpenVPN ბინარული და კონფიგურაციის ფაილი და მაინც ჩავარდნენ პირველ ქსელურ გამოძახებაზე. შეცდომა ასახელებს /dev/net/tun-ს, რადგან აპლიკაციამ ბირთვს სთხოვა TUN ინტერფეისი, ხოლო კონტეინერს არც მოწყობილობის კვანძი ჰქონდა და არც მისი შექმნის შესაძლებლობა. ეს ორი ცალკე ნებართვაა და ერთის გასწორება მეორეს ზუსტად იქ ტოვებს, სადაც იყო.

მათი განცალკევებისთვის თითო ბრძანებაა საჭირო. შემდგომი შეცდომის შეტყობინება გეტყვით, რომელ საზღვარზე იდექით სინამდვილეში.

მოწყობილობის კვანძი და შესაძლებლობა ორი კარია

მოწყობილობის კვანძი ფაილური სისტემის ობიექტია, ამიტომ კონტეინერმა ის საკუთარ mount-სახელთა სივრცეში უნდა დაინახოს. შესაძლებლობა ნებართვაა, ამიტომ პროცესს CAP_NET_ADMIN სჭირდება იმ სახელთა სივრცეში, სადაც ინტერფეისი შეიქმნება. მოწყობილობის გადაცემა შესაძლებლობის გარეშე გაძლევთ კვანძს, რომელიც იხსნება, და ioctl-ს, რომელიც ვარდება. შესაძლებლობის მიცემა მოწყობილობის გარეშე აპლიკაციას რაიმეს გახსნის უნარს ართმევს, ამიტომ ორივე ჩვეულებრივ ერთად ჩნდება მაგალითებში.

Docker-ის devices პარამეტრი მასპინძლის მოწყობილობას კონტეინერში ასახავს, ხოლო 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 პოლიტიკას, რომელიც ოპერაციას ზღუდავს. ეს მესამე საზღვარია, რომელსაც გაშვების გარემო ადასტურებს და არა აპლიკაცია.

ჩაწერეთ კონტეინერის დროშები, იმიჯი და ყოველი ცდის ზუსტი შეცდომა. შემდეგი ადამიანი, რომელიც ამ ჩანაწერს წაიკითხავს, შეძლებს თქვას, რომელი კარი იყო დაკეტილი მთელი გამოძიების გამეორების გარეშე.

დაკავშირებული სტატიები