VPN კლიენტს SSH-ით უშვებთ? ჯერ საკუთარი მარშრუტი დაამაგრეთ
სრული გვირაბის კლიენტი გადაწერს ცხრილს, რომელიც თქვენს SSH პასუხს ატარებს. დაამაგრეთ ერთი ჰოსტის მარშრუტი ძველი კარიბჭის გავლით, ან გაუშვით კლიენტი საკუთარ სახელთა სივრცეში.
SSH-ით შედიხართ build ჰოსტზე, იქ იწყებთ VPN კლიენტს და სესია პასუხს წყვეტს. არაფერი ჩამოვარდნილა და არაფერი არ გამოიყურება არასწორად კონფიგურირებულად აშკარა გაგებით. კლიენტმა დააყენა ნაგულისხმევი მარშრუტი, ამიტომ თქვენს სამუშაო სადგურზე პასუხები ახლა გვირაბიდან გადის, სადაც თქვენი სამუშაო სადგურის მისამართი მარშრუტიზაციადი არ არის. საინტერესო ის არის, რომ ეს შედეგი წინასწარ ცნობადი იყო, და შესწორება ერთი მარშრუტია, რომელიც კლიენტის გაშვებამდე იწერება. დავუშვათ სერვერი ერთი ქსელური ბარათით, კარიბჭე 192.0.2.254 და ადმინისტრატორი, რომელიც 203.0.113.9-დან უკავშირდება.
ჩაწერეთ გზა სანამ დაიწყებთ
ip route show default ამჟამინდელ კარიბჭესა და ინტერფეისს ასახელებს, ხოლო ip route get 203.0.113.9 აჩვენებს, რომელ ინტერფეისსა და წყაროს მისამართს გამოიყენებდა ბირთვი თქვენი სესიისთვის. შეინახეთ ორივე გამოტანილი შედეგი. გვირაბის აწევის შემდეგ ეს ორი ბრძანება კვლავ ფიზიკურ გზას უნდა აღწერდეს, ხოლო თუ ისინი სამაგიეროდ გვირაბს აღწერენ, სესია უკვე ნასესხებ დროზე ცხოვრობს.
მნიშვნელოვანია უკვე დამყარებული კავშირი, ამიტომ ნუ გადაამოწმებთ მხოლოდ ახალი შესვლით. ახალი სესია შეიძლება მოკლედ წარმატდეს იმ მდგომარეობის მეშვეობით, რომელიც ძველს აღარ აქვს.
დაამაგრეთ მისამართი თავად კლიენტის კონფიგურაციაში
ხელით დამატებული მარშრუტი გადატვირთვისას ქრება და კლიენტის საკუთარ ცხრილის განახლებებს ეჯიბრება, ამიტომ გამონაკლისი ჩადეთ იქ, სადაც ცხრილი იმართება. OpenVPN-ში net_gateway საკვანძო სიტყვა იმ კარიბჭეში იხსნება, რომელიც გვირაბამდე არსებობდა, ამიტომ route 203.0.113.9 255.255.255.255 net_gateway ზუსტად ერთ მისამართს ინახავს მის გარეთ. WireGuard-ს სხვა მიდგომა სჭირდება, რადგან wg-quick თავად მართავს მარშრუტებს: დააყენეთ Table = off და დაამატეთ გამონაკლისი PostUp-ში, შესაბამის PostDown-თან ერთად, რომელიც მას შლის. ორივე ფორმა ერთსა და იმავე განზრახვას გამოხატავს და ორივე გამონაკლისს ერთ მისამართზე ზღუდავს, ყველაფრისთვის გვირაბის შესუსტების ნაცვლად.
IPv6-ისთვის იგივე იდეა ერთი ჰოსტის პრეფიქსს იღებს, და შეფუთული ტრანსპორტის შემთხვევა ღირს დამახსოვრებად: თუ თავად გვირაბის გარე კავშირი ფიქსირებულ მისამართზე ცხოვრობს, ის მისამართი უნდა დარჩეს იმ გვირაბის გარეთ, რომელსაც ის ატარებს, წინააღმდეგ შემთხვევაში კლიენტი საკუთარ ტრანსპორტს საკუთარ თავში მარშრუტიზაციას უკეთებს.
ან ამოიღეთ მთავარი ცხრილი განტოლებიდან
როცა ჰოსტზე რამდენიმე სერვისმა უნდა შეინარჩუნოს თავისი ჩვეულებრივი გზა, შეწყვიტეთ მთავარი ცხრილის რედაქტირება და მიეცით კლიენტს საკუთარი. veth წყვილის მქონე ქსელური სახელთა სივრცე ამას სუფთად აკეთებს: კლიენტის ნაგულისხმევი მარშრუტი სხვა სტეკში ცხოვრობს და გვირაბს მხოლოდ მის შიგნით გაშვებული პროცესები იყენებენ. პოლიტიკური მარშრუტიზაცია ერთი დანიშნულებისთვის მსგავს ადგილს აღწევს, შესაბამის ტრაფიკს გამოყოფილ ცხრილში აგზავნის, რომლის ნაგულისხმევი კვლავ ფიზიკურ კარიბჭეზე მიუთითებს. ორივე მიდგომა ჰოსტის მთავარ ცხრილს ახალი ნაგულისხმევი მარშრუტის გარეშე ტოვებს, და სწორედ ეს თვისება ინახავს SSH-ს პასუხის გაცემის რეჟიმში.
ორივე ერთ ჰოსტის მარშრუტზე მეტი მექანიზმია და ორივე ღირს, როცა მანქანაზე ერთზე მეტმა რამემ უნდა გადაიტანოს გვირაბი.
დავუშვათ, რომ დამაგრება შეიძლება ჩავარდეს
თქვენს მიმდინარე საჯარო მისამართზე მიბმული მარშრუტი იმ წუთას იშლება, როცა თქვენი პროვაიდერი მას ხელახლა ანიჭებს. მაშინ დისტანციურ სერვერს სჭირდება გზა, რომელიც ამ მისამართზე არ არის დამოკიდებული: კონსოლი, მეორე მართვის ინტერფეისი, ან ნახტომა ჰოსტი, რომელიც გვირაბის გარეთ რჩება.
ორი დამცავი ღონისძიება ათი წუთი ღირს. მცველი, რომელიც კლიენტს აჩერებს, თუ დამადასტურებელი შესვლა რამდენიმე წუთში არ გამოჩნდა, ჩაკეტვას დაყოვნებად აქცევს, და ცვლილების დროს ღიად დატოვებული მეორე SSH სესია ამტკიცებს, რომ გამონაკლისი მუშაობს, სანამ გვირაბი აწეულია. მხოლოდ keepalive-ები აქ არ ეხმარება, რადგან გზა გაქრა და არა უმოქმედოა; ისინი მხოლოდ სიკვდილის შემჩნევას აადვილებენ.
გადაამოწმეთ იმ თანმიმდევრობით, რომელსაც მნიშვნელობა აქვს
შეაერთეთ გვირაბი, დაადასტურეთ, რომ თქვენს მისამართამდე მარშრუტი კვლავ ფიზიკური კარიბჭიდან გადის, შემდეგ გახსენით ახალი სესია. თუ ახალი სესია მუშაობს და ძველი მაინც კვდება, მიზეზი მარშრუტიზაცია არ არის, არამედ კავშირების თვალყურის დევნება ან მდგომარეობის მქონე firewall, რაც სხვა შესწორებაა.
ჩაწერეთ დამაგრებული მისამართი და ბრძანება, რომელმაც ეს დაამტკიცა, ცვლილებების ჟურნალში. შემდეგ ადამიანს, ვინც ამ ჰოსტზე კლიენტს გაუშვებს, ორივე დასჭირდება, და მისამართი შეიძლება მანამდე შეიცვალოს.