FreeBind After= -ის წინააღმდეგ: systemd-ის socket-ის VPN მისამართზე მიბმა

ჩატვირთვისას ფიქსირებულ VPN მისამართზე მბმელი socket-ერთეული შეიძლება ჩავარდეს მანამ, სანამ გვირაბი მას მიანიჭებს, და მის უკან მდგარი სერვისი არასდროს ამოქმედდება. ორი გადამრთველი შესწორებას ჰგავს და ამ პრობლემის სხვადასხვა ნახევარს წყვეტს. FreeBind საშუალებას აძლევს systemd-ს შექმნას მსმენელი, სანამ მისამართი ჯერ კიდევ არ არსებობს. After= მხოლოდ სამუშაოებს აწესრიგებს, ამიტომ ცვლის, როდის იწყება რამ, მაგრამ მისამართს ადრე არ მოიტანს.

ორი განსხვავებული პრობლემა, ორი განსხვავებული გადამრთველი

პირველი პრობლემა მიბმის ჩავარდნაა: ბირთვი უარყოფს მოსმენას მისამართზე, რომელსაც ჰოსტი არ ფლობს, ამიტომ socket-ერთეული მაშინვე ჩავარდება და სერვისი არასდროს გააქტიურდება. მეორე პრობლემა მზადყოფნის ჩავარდნაა: მისამართი საბოლოოდ არსებობს, მაგრამ რაღაც მის გამოყენებას ცდილობს მანამ, სანამ გვირაბი ტრაფიკს გადაიტანს. FreeBind პირველს უმკლავდება და მეორისთვის არაფერს აკეთებს. რიგის დირექტივები არც ერთს არ უმკლავდება პირდაპირ, რადგან ისინი მხოლოდ წყვეტენ, რა რა თანმიმდევრობით იწყება. იმ ჩავარდნის დასახელება, რომელიც ნამდვილად გაქვთ, მთელი გადაწყვეტილებაა.

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

FreeBind: მსმენელი მისამართამდე არსებობს

FreeBind ეუბნება ბირთვს, დაუშვას მიბმა არალოკალურ მისამართზე, რათა systemd-მა შეძლოს მოსმენის socket-ის შექმნა ჩატვირთვისას და გადასცეს იგი აპლიკაციას, როცა აპლიკაცია დაიწყება. ეს არის socket-აქტივაციის არსი და მიზეზი, რის გამოც socket-ს შეუძლია გადააჭარბოს მის უკან მდგარ სერვისს.

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

ცარიელი მინიჭება შლის მომწოდებლის ერთეულიდან მემკვიდრეობით მიღებულ მოსმენის ჩანაწერებს ახლის დამატებამდე, რაც ხელს უშლის დარჩენილ wildcard-მსმენელს ყველა ინტერფეისზე პასუხის გაცემაში. შეცვალეთ მისამართი და პორტი თქვენით და შეამოწმეთ ეფექტური ერთეული და არა მხოლოდ drop-in ფაილი. პაკეტის ფაილის ადგილზე რედაქტირების ნაცვლად გამოიყენეთ drop-in ერთეულის სახელქვეით, რადგან შემდეგი პაკეტის განახლება გადაფარავს რედაქტირებას და განზრახვის კვალს არ დატოვებს. შემდეგ გამოიყენეთ იგი გადატვირთვისა და ხელახლა გაშვების იმ პროცედურით, რომელსაც socket-ერთეული მოელის.

systemd socket-ის ცნობარი აღწერს ამ პარამეტრის უკან არსებულ IPv4 და IPv6 ქცევას, და მთავარი დეტალი ის არის, რომ იგი მიბმას ეხება და არა მარშრუტიზაციას. მასში არაფერი ანიჭებს მისამართს და არ იწყებს VPN-ს. FreeBind მსმენელისთვის მიცემული ნებართვაა და არა ინტერფეისის შემცვლელი.

After= და Wants=: რიგი მზადყოფნა არ არის

რიგი და მოთხოვნა ცალკე ღერძებია და მათი არევა ქმნის ერთეულებს, რომლებიც სწორი რიგით იწყება და მაინც ჩავარდება. After=vpn-client.service ნიშნავს მხოლოდ იმას, რომ თუ ორივე სამუშაო დაიწყება, ეს დაელოდება მეორის დაწყებას. ის არ ჩათრევს VPN-ს და არ დაელოდება VPN-ის დაკავშირების დასრულებას.

მოთხოვნის დირექტივები, როგორიცაა Wants= და Requires=, აქტივაციას მართავს და განსხვავდებიან იმით, თუ რა ხდება დამოკიდებულების ჩავარდნისას: ერთი აგრძელებს, მეორე ჩერდება. არც ერთმა არ იცის, რას ნიშნავს დაკავშირებული გვირაბი. VPN პროცესი შეიძლება აქტიური იყოს მინიჭებული მისამართის გარეშე, ან მინიჭებული მისამართით და წყვილამდე მარშრუტის გარეშე, და ორივე მდგომარეობა აკმაყოფილებს დამოკიდებულებას. თუ აპლიკაციას სჭირდება მისამართის არსებობა, დაამოდელეთ ეს პირობა ცხადად, ნაცვლად იმისა, რომ პროცესის დაწყება მზადყოფნის მტკიცებულებად ჩათვალოთ.

შეამოწმეთ, რას აცხადებს ერთეული სინამდვილეში, systemctl cat და systemctl show -p After -p Wants -p Requires-ის მეშვეობით. სამი სხვადასხვა დირექტორიის drop-in-მა შეიძლება დაამატოს დირექტივები, რომლებიც არასდროს დაგიწერიათ, და systemd მხოლოდ ეფექტურ ერთეულს კითხულობს.

რას არ აკეთებს network-online.target

network-online.target-ის შემდეგ დალაგებული ერთეული დაელოდება ქსელის მენეჯერის მიერ ქსელის გამოსადეგად გამოცხადებას, რაც ჩატვირთვის სინქრონიზაციის წერტილია და არა უწყვეტი პირობა. ის არაფერს ამბობს იმაზე, არის თუ არა კონკრეტული გვირაბი აწეული, და აღარ ამოქმედდება, როცა VPN შუადღის შემდეგ ხელახლა დაუკავშირდება. მისი ხელახალი დაკავშირების მონიტორად მიჩნევა ამ სამიზნის ყველაზე გავრცელებული არასწორი წაკითხვაა.

systemd პროექტი ამ განსხვავებას პირდაპირ ასაბუთებს და პრაქტიკული შედეგი ის არის, რომ გვირაბის მისამართის მქონე ყველაფერმა თავად უნდა ფლობდეს დამოკიდებულებას. ერთეული, რომელიც network-online-ს დაელოდება და შემდეგ გვირაბის მისამართს მიბამს, მართებულია მხოლოდ მაშინ, როცა გვირაბი შემთხვევით პირველი ადის, და ეს შემთხვევითობაა და არა დიზაინი.

შეამოწმეთ სასიცოცხლო ციკლი, რომელიც ნამდვილად აირჩიეთ

შეამოწმეთ სუფთა ჩატვირთვა, მოთხოვნა მისამართის გამოჩენის შემდეგ და ქცევა მას შემდეგ, რაც VPN ჩამოვარდება და დაბრუნდება. ეს სამი შემთხვევა ერთმანეთისგან ჰყოფს მომუშავე მსმენელსა და მომუშავე სერვისს.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

პირველი ბრძანება იჭერს ერთეულის ფაილის შეცდომებს გადატვირთვამდე, მეორე აჩვენებს გაერთიანებულ ერთეულს, ხოლო მესამე ამტკიცებს, არსებობს თუ არა მსმენელი და რომელ მისამართზე. მსმენელი wildcard მისამართზე იქ, სადაც გვირაბის მისამართს ელოდებოდით, ზუსტად ის ნარჩენია, რომელიც ცარიელ ListenStream-ს უნდა მოეშორებინა. გაიმეორეთ მესამე ბრძანება VPN-ის ხელახალი დაკავშირების შემდეგ, რომ ნახოთ, გადავიდა თუ არა მისამართი.

აირჩიეთ სასიცოცხლო ციკლი განზრახ: ან თავისუფლად მიბმული მსმენელი, რომელიც სტაბილური მისამართის დაბრუნებას ელოდება, ან სერვისი, რომელიც გვირაბთან ერთად ჩერდება და აღდგენისას ხელახლა იწყება. ეს სხვადასხვა დიზაინია და სხვადასხვაგვარად ჩავარდება. შემდეგ შეინარჩუნეთ წვდომის პოლიტიკა მიბმული იმ წყაროებსა და ბილიკებზე, რომლებიც განიზრახეთ, რადგან დანიშნულების მისამართის მიბმა არ მოითხოვს, რომ მიღებული პაკეტები სანდო ინტერფეისით მოსულიყო.