ორი VPN ნახტომი ერთ Pi-ზე: რომელი მარშრუტი რომელ პარტნიორს ატარებს
ორი გვირაბის მისამართი ერთ Pi-ზე ხარვეზი არ არის. თითოეულ დანიშნულებას სჭირდება საკუთარი გადამტანი, საკუთარი მტკიცებულება და გამოცხადებული სარეზერვო გეგმა, როცა გარე ნახტომი კვდება.
ორი გვირაბის მისამართი ერთ პატარა დაფაზე შეცდომად გამოიყურება და რეფლექსია ერთის წაშლა. ეს რეფლექსი ამტვრევს იმას, რაც უნდა მოეწესრიგებინა. ორი ნახტომის მატარებელი ჰოსტი ინახავს ერთ მისამართს თითო კავშირზე და თითოეულ მისამართს სხვადასხვა მარშრუტი ირჩევს. საკითხავი კითხვაა რომელი მარშრუტი ირჩევს რომელ გადამტანს რომელი დანიშნულებისთვის და არა რამდენი მისამართი არსებობს.
სამი დანიშნულება, რომლებსაც სხვადასხვა გადამტანი სჭირდებათ
ორი ნახტომის ჯაჭვი სამი დანიშნულების კლასია ერთმანეთზე დალაგებული და თითოეულს სხვადასხვა კავშირი ატარებს. გარე პარტნიორამდე ფიზიკური ბმულით უნდა მივაღწიოთ. შიდა პარტნიორამდე გარე გვირაბით უნდა მივაღწიოთ. დაფარული აპლიკაციის დანიშნულებამდე შიდა გვირაბით უნდა მივაღწიოთ, რომლის საკუთარ ტრანსპორტსაც გარე ატარებს.
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
შეავსეთ რიგები მკითხველის რეალური მისამართებით, სანამ მარშრუტს შეეხებით, რადგან ცხრილი მხოლოდ მაშინ არის სასარგებლო, როცა კონკრეტულია. მომუშავე ჯაჭვი ოთხივე რიგს ერთდროულად აკმაყოფილებს, ხოლო ნახევრად მომუშავე ჯაჭვი ჩვეულებრივ ერთ-ერთს არასწორი გადამტანით აკმაყოფილებს. სწორედ არასწორი რიგის ხარვეზად წაკითხვა აქცევს მარშრუტიზაციის პრობლემას მთელ შუადღედ რედაქტირებისა.
მისამართებს როლები აქვთ და არა რაოდენობა
Linux ერთ ინტერფეისზე რამდენიმე მისამართს და ერთ ჰოსტზე რამდენიმე გვირაბს იძლევა, ამიტომ რაოდენობა სისწორეზე არაფერს ამბობს. მნიშვნელოვანია, რომელი მისამართი რომელ კავშირს ეკუთვნის და ირჩევს თუ არა მოცემული პარტნიორის მარშრუტი იმ კავშირს, რომელიც გულისხმობდით. სამი ხედი ამას სამი მიმართულებიდან პასუხობს და ღირს მათი ყოველ ჯერზე იმავე თანმიმდევრობით წაკითხვა.
მისამართების ინვენტარი აჩვენებს, რა არსებობს და რომელი კავშირი ფლობს მას. მარშრუტების ცხრილი პასუხობს გადამტანის კითხვას ჩვეულებრივი დანიშნულების ტრაფიკისთვის. პოლიტიკის ხედი კვლავ პასუხობს მას წყაროთი ან ნიშნით შერჩეული ტრაფიკისთვის, რაც ჩვეულებრივი განლაგებაა, როცა ორი კლიენტი ერთ ჰოსტს იზიარებს.
ip -4 addr show
ip -4 route show table all
ip rule showმისამართის წაშლამ იმიტომ, რომ სია გრძლად გამოიყურება, შეიძლება გზის ნაწილი მოხსნას, ხოლო მარშრუტის წაშლამ იმიტომ, რომ ზედმეტად გამოიყურება, იგივე უფრო ჩუმად გააკეთოს. არც ერთი არ იძლევა შეცდომას; პარტნიორი უბრალოდ წყვეტს პასუხს იმ გზაზე, რომელიც გულისხმობდით, სანამ სხვა გზით მისაწვდომი რჩება. აპლიკაცია, რომელიც იტყობინება შიდა პარტნიორის გასასვლელ მისამართს, არ ამტკიცებს, რომ ტრაფიკმა გარე გვირაბი გადაკვეთა, რადგან პირდაპირი წვდომა იგივე დაკვირვებას იძლევა. სწორედ ეს უფსკრული დაკვირვებასა და მტკიცებულებას შორის არის მიზეზი, რომ გადამტანს მარშრუტიზაციის დონეზე ამოწმებენ.
გააქტიურების რიგი სჯობს ფიქსირებულ ძილს
თუ შიდა კლიენტი დამოკიდებულია მისამართზე ან მარშრუტზე, რომელსაც გარე კლიენტი აწვდის, გააქტიურებამ უნდა დაელოდოს ამ რესურსს და არა დაყოვნებას. ძილი მუშაობს იმ დღემდე, როცა გარე გვირაბი ნელი იქნება, და შემდეგ ის დროდადრო ისე ვარდება, რომ ვერავინ ვერ გაიმეორებს. დამოკიდებულებებზე დაფუძნებული რიგი აშორებს ვარაუდს და არაფერი ღირს დამოკიდებულების ერთხელ აღწერის გარდა. ინტერფეისების სახელებიც არ არის რიგის მექანიზმი.
ბირთვი ანიჭებს სახელებს, როგორიცაა tun0 და tun1, შექმნის რიგით და ეს რიგი შეიძლება შეიცვალოს გადატვირთვებსა თუ ხელახალ დაკავშირებებს შორის. მიაბით კონფიგურაცია ხელსაწყოს მიერ მოწოდებულ იდენტობას ან სახელს, რომელსაც განზრახ ანიჭებთ. სახელი, რომელსაც თქვენ ირჩევთ, ხელშეკრულებაა; სახელი, რომელსაც ბირთვი ირჩევს, შემთხვევითობაა.
შეინარჩუნეთ თითოეული კლიენტის ტრანსპორტი მეორის აპლიკაციის მარშრუტის გარეთ და იყავით ზუსტი იმაში, რასაც OpenVPN 2.6-ის მარშრუტიზაციის პარამეტრები რეალურად გვპირდება. დოკუმენტირებული ნაგულისხმევი გადამისამართების მექანიზმი კლიენტს ინარჩუნებს უნარს მიაღწიოს საკუთარ შორეულ პარტნიორამდე უკვე არსებული კარიბჭის გავლით, რაც ერთ კონკრეტულ რეკურსიულ ციკლს წყვეტს. ის ერთ კლიენტს მეორის გადამტანად არ აქცევს, ამიტომ ჯაჭვის დარჩენილი ნაწილი თქვენი დიზაინი რჩება. სადაც ჯაჭვს მარშრუტის ნაცვლად პოლიტიკა სჭირდება, დაწერეთ აშკარა წყაროს ან ნიშნის წესი და გამოსცადეთ იმ ტრაფიკით, რომელსაც უნდა შეესაბამებოდეს.
რა ხდება, როცა გარე ნახტომი კვდება
სანამ ჯაჭვი დასრულებულად ჩაითვლება, გადაწყვიტეთ, რა მოხდება, როცა გარე ნახტომი გაქრება. შიდა კლიენტის ტრანსპორტი მასთან ერთად კვდება და შემდეგი ნაბიჯი ტექნიკური კი არა, პოლიტიკური კითხვაა: ჩავარდნა, ხელახლა ცდა თუ ფიზიკური ბმულით პირდაპირ ხელახლა დაკავშირება. სწორედ მესამე შედეგია ღირსი დაფიქრებისა. ის ჩუმად აქცევს ორი ნახტომის დიზაინს ერთი ნახტომის დიზაინად იმ მომენტში, როცა მომხმარებელი ფიქრობს, რომ დაფარვა ჯერ კიდევ ხელუხლებელია.
თუ ორი ნახტომი სავალდებულოა, შიდა კლიენტს არ უნდა შეეძლოს პირდაპირი გზის დაყენება, როცა გარე გაქრა, და ამის გასაგებად გარე ნახტომი უნდა გატყდეს და დავაკვირდეთ, რას აკეთებს შიდა. დამტკიცებული სარეზერვო გეგმა ლეგიტიმური პასუხია, მაგრამ ის უნდა დაიწეროს, გამოიცადოს და გამოცხადდეს. სარეზერვო გეგმა, რომელიც არავის დაუდგენია, ინციდენტის განხილვისას გაჟონვისგან არ გაირჩევა.
DNS და მისამართების მეორე ოჯახი ერთსა და იმავე გადაწყვეტილებას მიეკუთვნება. ლოკალურად გენერირებული მოთხოვნა ჰოსტის საკუთარ პოლიტიკას მიჰყვება და არა გადაცემული კლიენტისას, ამიტომ გადაცემული ტრაფიკისთვის მომუშავე მამძლევი შეიძლება არ იყოს ის, რომელსაც თავად ჰოსტი იყენებს.
მიიღეთ თითოეული ფენა იმ რიგით, რომლითაც ააგეთ
გამოსცადეთ იმ რიგით, რომლითაც ჯაჭვი აშენდა: ჯერ მხოლოდ გარე გვირაბი, შემდეგ შიდა კლიენტის ტრანსპორტი გარე გვირაბით, შემდეგ აპლიკაცია შიდა გვირაბით. თითოეული მიღება უნდა იყოს ახალი კავშირი და არა უკვე გახსნილი გვერდი. შემდეგ დაამტვრიეთ და აღადგინეთ თითოეული ფენა ცალ-ცალკე და დააკვირდით, რას აკეთებს შემდეგი.
სარეზერვო გეგმის შედეგი აქ ყველაზე ღირებული დაკვირვებაა და ის, რასაც საჯარო IP-ის გვერდი არასოდეს აჩვენებს. შეინახეთ პარტნიორების გზები, მათ მიერ გამოყენებული მისამართები და ეს შედეგი კონფიგურაციის გვერდით, რადგან ბედნიერი გზა არ არის ის ნაწილი, რომელზეც მოგვიანებით ეჭვი აღიძვრება.