ifconfig-noexec თქვენს SSH სესიას არ იხსნის: რას აკეთებს ის სინამდვილეში
ის თრგუნავს OpenVPN-ის საკუთარი ინტერფეისის მისამართის კონფიგურაციას. ის არ იტოვებს SSH-ის პასუხის მარშრუტს, არ თიშავს ყველა მარშრუტის ცვლილებას და არ აძლევს დაკარგულ მისამართს.
რომელიღაც ფორუმის თემაში ifconfig-noexec შემოთავაზებულია როგორც გამოსავალი, რომელიც SSH სესიას ცოცხლად ინარჩუნებს, როცა გვირაბი ამოდის. მსჯელობა დამაჯერებლად ჟღერს, სანამ არ შეამოწმებ, რას ეხება ეს ოფცია. ის ხელს უშლის OpenVPN-ს გვირაბის ინტერფეისის მისამართის კონფიგურაციაში და ეს მნიშვნელობები სკრიპტებს გადასცემს; იმაზე კი არაფერს ამბობს, სად მიდის პასუხები შენი მართვის კავშირზე. საპირისპიროს რწმენა ქმნის გვირაბს გამოსაყენებელი მისამართის გარეშე და SSH სესიას, რომელიც მაინც იღუპება.
რას გადასცემს ეს ოფცია სინამდვილეში
ნაგულისხმევად კლიენტი გვირაბის მოწყობილობას რთავს და ანიჭებს ლოკალურ და დისტანციურ მისამართებს, რომლებიც სერვერმა მისცა. როცა ifconfig-noexec დაყენებულია, ეს ნაბიჯი გამოტოვებულია და შეთანხმებული მნიშვნელობები სკრიპტის გარემოში ექსპორტირდება, რომ სხვამ შეძლოს მათი გამოყენება.
მფლობელობა გადადის. მის ნაცვლად არაფერი არ იგონება.
ასე რომ, კითხვა, რომელზეც ოფცია პასუხობს, არის ვინ აკონფიგურირებს ინტერფეისს, და კითხვა, რომელზეც ის არ პასუხობს, არის როგორ პოულობენ პაკეტები უკანა გზას შენამდე. ეს ორი ცალ-ცალკე შეინახე, თორემ მთელ საღამოს მარშრუტების რედაქტირებაში გაატარებ, რომ მისამართის გარეშე ინტერფეისი აანაზღაურო.
სამი მსგავსი ოფცია განსხვავებული საქმით
ამ ოჯახის არევა ადვილია, რადგან სახელები ერთი სიტყვით განსხვავდება და სიმპტომები ერთმანეთს ეფარება. წაიკითხე, რას თრგუნავს თითოეული, სანამ რომელიმეს აირჩევ.
| Option | What stops happening |
|---|---|
ifconfig-noexec | OpenVPN's own tunnel-address configuration; values go to scripts instead |
route-noexec | Automatic route addition and removal; route details go to a script |
route-nopull | Server-pushed routes and related options such as DNS are rejected |
ესენი ცალ-ცალკე გასაგები ალტერნატივებია და არა ერთად ჩასაწებებელი ნაკრები. მისამართის კონფიგურაციის დათრგუნვა არ თრგუნავს მარშრუტის ცვლილებებს, ფაირვოლის წესებს ან DNS-ის მატარებელ გაგზავნილ ოფციებს. გადაცემულ სკრიპტსაც შეუძლია მარშრუტების შეცვლა, და ეს არის გადაწყვეტილება, რომელსაც გადასცემ და არა თავს არიდებ.
თუ მომწოდებლის კლიენტი ძრავს ახვევს, გამოიყენე მისი მხარდაჭერილი ინტეგრაცია იმის ნაცვლად, რომ პროფილში დაბალი დონის დირექტივა ჩააგდო და იმედი იქონიო, რომ გარსი მას პატივს სცემს. გარსები ხშირად კავშირის დროს პროფილს ხელახლა ქმნიან, ამიტომ ხელით ცვლილება შეცდომის გარეშე ქრება. სანამ ფაილზე მთელ საღამოს დახარჯავ, შეამოწმე, სად ინახავს კლიენტი პარამეტრებს. ეს ეხება ცხრილის ყველა სტრიქონს და არა მხოლოდ იმას, რისთვისაც მოხვედი.
ის SSH სესია, რომლის დაცვაც გინდოდა
SSH კავშირს აქვს წყაროს მისამართი, დანიშნულების მისამართი და პასუხის გზა. სერვერზე, რომელმაც ახლახან დააყენა სრული გვირაბის ნაგულისხმევი, შენს საჯარო მისამართზე პასუხი გვირაბს ემთხვევა და VPN-ის კარიბჭე მას აგდებს.
გვირაბის ინტერფეისის მისამართის კონფიგურაციაში არაფერი ცვლის ამას.
რაც ამას ასწორებს, არის უფრო კონკრეტული მარშრუტი შენი მართვის მისამართისთვის გვირაბამდე არსებული კარიბჭის გავლით, ან პოლიტიკის წესი, რომელიც ამ ტრაფიკს მიმართავს, და დამატებით ის ფილტრის პარამეტრები, რომლებსაც შენი ჰოსტი იყენებს. ორი პრობლემა ზოგჯერ ერთად ჩნდება და სწორედ ასე აღიქმება ერთი მეორის სამკურნალოდ. ცალ-ცალკე გამოსცადე: გვირაბი ოფციის გარეშე აწიე, შეხედე ინტერფეისის მისამართს და პასუხის გზას, შემდეგ გადაწყვიტე, ორიდან რომელია ნამდვილად გატეხილი.
რა უნდა აიღოს გადაცემულმა სკრიპტმა
თუ ნამდვილად გინდა, რომ სხვა მფლობელმა დააკონფიგურიროს ინტერფეისი, ჩამოთვალე სამუშაო: გამოიყენე ლოკალური და დისტანციური მისამართი, აწიე მოწყობილობა, აღადგინე ან წაშალე მისამართები გათიშვისას და იგივე გაიმეორე ხელახალი კავშირის შემდეგ. ერთი წარმატებული სესიის მნიშვნელობები არ უნდა იყოს ჩაშენებული, რადგან სერვერმა შეიძლება შემდეგ ჯერზე სხვა წყვილი მოგცეს.
კლიენტის მიერ ექსპორტირებული გარემოს ცვლადები ამ სამუშაოს ერთადერთი მხარდაჭერილი შეყვანაა.
env | grep -E '^ifconfig_|^route_'რომელიმე route-up სკრიპტის შიგნით ეს ცვლადები ხელმისაწვდომია; cron-ის დავალებიდან ან ხელით გაშვებული shell-იდან არა. დაადასტურე, რომელ სასიცოცხლო ციკლის კაუჭს იყენებს შენი ვერსია და რომ კაუჭი ინტერფეისის შესაცვლელად საკმარისი უფლებებით მუშაობს, რადგან კლიენტი შეიძლება უკვე დაშვებული იყოს არაპრივილეგირებულ მომხმარებელზე.
გამოსცადე მთელი სასიცოცხლო ციკლი და არა ერთი სესია
აწიე გვირაბი, შეამოწმე მისამართი მოწყობილობაზე, შემდეგ ხელახლა დაუკავშირდი და კვლავ შეამოწმე. კონფიგურაცია, რომელიც ერთხელ მუშაობს და მეორე ცდაზე ფუჭდება, ჩვეულებრივ ნიშნავს, რომ გადაცემული ნაბიჯი მხოლოდ პირველ კავშირზე მუშაობს.
შემდეგ ორივე მიღების კრიტერიუმი ერთად გამოსცადე: განზრახული მართვის გზით ახალი SSH კავშირი მუშაობს და დაშვებული აპლიკაცია გვირაბს სწორად იყენებს.
ძველი SSH სესია, რომელიც შემთხვევით რჩება ცოცხალი, როცა გვირაბს მისამართი არ აქვს, წარმატება არ არის და ეს ზუსტად ის მდგომარეობაა, რომელსაც ეს ოფცია ქმნის, როცა არავინ იღებს სამუშაოს. ჯერ ინტერფეისის მისამართი შეამოწმე, შემდეგ მართვის პასუხის გზა, შემდეგ აპლიკაცია. თუ სამიდან ორი არასწორია, ოფციამ სამუშაო გადაიტანა, მაგრამ მფლობელი არ მისცა.