სერვერი თუ კლიენტი: რომელი OpenVPN ერთეული ორმაგი როლის Pi-ზე

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

შეუსაბამეთ ერთეულის სახელი იმ საქაღალდეს, რომელსაც ის ტვირთავს

Upstream 2.6 ორ შაბლონურ ერთეულს აწვდის, [email protected] და [email protected]. სერვერის შაბლონი იწყება /etc/openvpn/server-ში და იქიდან ტვირთავს %i.conf-ს. კლიენტის შაბლონი იწყება /etc/openvpn/client-ში. ინსტანცია სახელად roaming შეიძლება ერთდროულად ორივე ადგილას არსებობდეს, როგორც სერვერი და როგორც კლიენტი, ორი დაუკავშირებელი კონფიგურაციით და მათ შორის რაიმე კავშირის გარეშე, გარდა სტრიქონისა.

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

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

გადაწყვიტეთ პაკეტის მიმართულებით, და არა ინტერფეისის სახელით

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

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

სანამ თეორიას ააგებთ, სოკეტებს შეხედეთ. udp/1194-ზე მიბმული სერვერი მსმენ სოკეტს აჩვენებს. კლიენტი დამარაგებლის მისამართთან კავშირს აჩვენებს და არაფერს, რაც უსმენს.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

ერთი ინსტანციის ნაგულისხმევმა მარშრუტმა შეიძლება მეორის პასუხები ჩაიგდოს

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

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

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

ip route get 203.0.113.44
ip rule show

გადატვირთეთ ერთი როლი და დაამტკიცეთ, რომ მეორემ გადარჩა

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

ცვლილებამდე ჩამოწერეთ გაჩერების პირობა: ზედა გვირაბის დაკარგვა ბლოკავს მოხეტიალე მომხმარებლებს, თუ უბრუნდება Pi-ის საკუთარ ზედა არხს? DNS-ს და IPv6-საც ცხადი პასუხი სჭირდება, რადგან გაგზავნილი ამომხსნელი ხშირად უფრო დიდხანს ცოცხლობს, ვიდრე მარშრუტი, რომელმაც ის სასარგებლო გახადა.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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