strongSwan-ში სრული გვირაბი ორივე მხარეს 0.0.0.0/0-ს მოითხოვს

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

ჯერ კლიენტის სელექტორი შეამოწმეთ

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

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

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

შეამოწმეთ კარიბჭის სელექტორი მისივე მხარეს

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

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

ძველი ipsec.conf მარცხენა და მარჯვენა როლებს სხვადასხვა გასაღებით იყენებს და rightsubnet ხაზი swanctl-ის მნიშვნელობის პირდაპირი ჩანაცვლება არ არის. ორი სინტაქსი ცალკე ფაილებში შეინახეთ, ერთის მეორეში ჩასმის ნაცვლად. მათი შერევა ერთ საქაღალდეში ის გზაა, რომლითაც მომუშავე კავშირი გადატვირთვის შემდეგ ჩუმად უკან ბრუნდება.

შეამოწმეთ მოლაპარაკებული child SA და არა ფაილი

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

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

პირველი ბრძანება გვიჩვენებს, რა ჩატვირთა დემონმა, მეორე — დადგენილი child SA-ები, ხოლო მესამე — ის პოლიტიკები, რომლებსაც ბირთვი გამოიყენებს. თუ ფაილი ამბობს 0.0.0.0/0-ს და სია ერთ ქვექსელს გვიჩვენებს, მოლაპარაკებამ მოცულობა შეავიწროვა და ფაილის ხელახლა წაკითხვა ამას არ ახსნის. შეწყვიტეთ child, ხელახლა გაუშვით და ისევ შეადარეთ სამივე გამოტანილი შედეგი. იმავე ვიწრო მოცულობით დაბრუნებული child შორეული მხარის მიერ არის შევიწროვებული და არა ლოკალური ფაილის, და ეს სხვა ადმინისტრატორთან საუბარია და არა ლოკალური ცვლილება.

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

შეამოწმეთ გადამისამართება და დაბრუნების მარშრუტი

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

შეამოწმეთ, რასაც გვირაბი ჯერ კიდევ არ ფარავს

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

ცხადად მიუთითეთ განზრახული DNS გზა, რადგან სრული გვირაბი, რომელიც სახელებს ჯერ კიდევ ლოკალური რეზოლვერით წყვეტს, შეკითხვებს გვირაბის გარეთ აჟონავს და კერძო სახელებს ამტვრევს. თუ კლიენტს IPv6 მისამართი გამოეყოფა, ამ მისამართების ოჯახსაც იგივე მოპყრობა სჭირდება, თორემ ჰოსტი უპირატესობას მისცემს გზას, რომელსაც გვირაბი არ იცავს. გამოსცადეთ სახელით, რომელზეც მხოლოდ კერძო მხარეს შეუძლია პასუხის გაცემა, და საჯარო პასუხი გაჟონვად ჩათვალეთ.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

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