ipsec.conf თუ swanctl.conf? აირჩიეთ strongSwan-ის ერთი ინტერფეისი

ძველი სახელმძღვანელოდან მომუშავე IKEv1 პროფილი Ubuntu 24.04-ზე ხვდება და პირველი ცდა ფარდება, რადგან დემონმა ფაილი არასოდეს წაიკითხა. ჩვეულებრივი რეაქცია პროფილის ხელახლა რედაქტირებაა. ნამდვილი კითხვაა, რომელი strongSwan ინტერფეისია დაყენებული და რომელს იყენებს მოქმედი სერვისი. სანამ ამას არ უპასუხებენ, ყოველი ცვლილება მიმართულია ჩამტვირთავზე, რომელიც შეიძლება არ არსებობდეს.

ორი ფაილი, ორი ჩამტვირთავი, ერთი დემონი

ძველი starter კონფიგურაცია კითხულობს ipsec.conf-ს და კავშირებს charon-ს გადასცემს თავისი ძველი მართვის ინტეგრაციით. მისი ოპერაციული შესვლის წერტილი ipsec ბრძანებაა.

swanctl კონფიგურაცია განსაზღვრებებს VICI-ის მეშვეობით ტვირთავს, კითხულობს swanctl.conf-ს და იმართება swanctl ბრძანებით. systemd-ის მშობლიური charon დემონი ამ მიდგომას ერწყმის.

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

წაიკითხეთ დაყენებული პაკეტები და unit-ები

დაიწყეთ მხოლოდ კითხვის რეჟიმში. პაკეტების სახელები Ubuntu 24.04-ზე ცალკეა: strongswan-starter, strongswan-swanctl და charon-systemd. არმყოფი პაკეტი სასარგებლო ინფორმაციაა, და არა მითითება მისი დაყენებისა.

ჩამოთვალეთ პაკეტები და unit-ები ერთი გავლით:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

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

თუ აქტიური unit არის strongswan-starter, მნიშვნელოვანი ფაილი ipsec.conf-ია. თუ ეს არის charon-systemd swanctl-ით, ipsec.conf მხოლოდ მორთულობაა.

გამოიყენეთ შესაბამისი მართვის გზა

თითოეულ ინტერფეისს კავშირებსა და ასოციაციებზე საკუთარი ხედვა აქვს. swanctl --list-conns აჩვენებს ჩატვირთულ განსაზღვრებებს, ხოლო swanctl --list-sas აქტიურ ასოციაციებს. ძველი გზა იყენებს ipsec statusall-ს.

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

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

ფორმატი IKE-ის ვერსია არ არის

ძველი პროფილი IKEv1-ს ირჩევს keyexchange=ikev1-ით. swanctl კავშირი იყენებს ვერსიის პარამეტრს, სადაც 1 ირჩევს IKEv1-ს. ეს ერთი იდეის ორი ლექსიკონია და არა გარდაქმნა.

პარტნიორის მისამართები, ლოკალური და დისტანციური იდენტობები, რწმუნებების წყაროები, წინადადებები და child სელექტორები განზრახ უნდა აისახოს. left/right ბლოკის swanctl სინტაქსში ჩასმა ამათგან არაფერს აკეთებს.

მხოლოდ პროტოკოლის ვერსიის შეცვლა ყველაზე გავრცელებული ნახევრად-მიგრაციაა. ის ქმნის ფაილს, რომელიც იტვირთება და შემდეგ ავთენტიფიკაციას ვერ გადის ვერსიასთან დაუკავშირებელი მიზეზებით. თავად IKEv1 RFC 9395-ით მოძველებულია, ამიტომ არსებული პარტნიორი, რომელიც ჯერ კიდევ ითხოვს მას, იმსახურებს დოკუმენტირებულ თავსებადობის შეზღუდვას და მიგრაციის გზას და არა ახალ ნაგულისხმევს.

შეამოწმეთ ჩამტვირთავი პროფილზე შეხებამდე

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

მართვის ორი გზა პირდაპირ პასუხობს ჩატვირთვის კითხვას:

swanctl --list-conns
ipsec statusall

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

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