ორი VPN ერთ Linux მანქანაზე: გამოსცადეთ თითოეული ცალკე, შედეგების შერევის გარეშე
ორი მწვანე ხატულა ჯერ არ არის შედარება. მოათავსეთ თითოეული გვირაბი საკუთარ სახელთა სივრცეში, ჯერ დაწერეთ მოლოდინი და დაამტკიცეთ გზა, სანამ შედეგს დაეყრდნობით.
ორი მწვანე კავშირის ხატულა შედარებას ჰგავს და ჩვეულებრივ შემთხვევითობაა. თუ სატესტო მოთხოვნას ორიდან რომელიმე გვირაბის გამოყენება შეეძლო, შედეგი საუკეთესო შემთხვევაში ერთ მათგანს აღწერს, უარესში კი არც ერთს. მიეცით ყოველ დაკვირვებას ქსელური კონტექსტი, განზრახული დანიშნულება და ტესტის გაშვებამდე დაწერილი მოლოდინი. თქვენ მიერ მართულ Linux მანქანაზე დასახელებული ქსელური სახელთა სივრცეები ამ გამიჯვნის შეძენის ყველაზე იაფი გზაა.
ორი მწვანე შუქი შედარება არ არის
სახელთა სივრცე ჰყოფს მარშრუტიზაციის ცხრილებს, ინტერფეისებს და ქსელური დასტის მდგომარეობას, ამიტომ ერთის შიგნით დაწყებული მოთხოვნა ვერ ისესხებს ჩუმად მეორის გვირაბს. რასაც ის არ ჰყოფს, არის პროცესორი, ფიზიკური აღმავალი არხი ან ჰოსტზე მომუშავე სახელების გადამწყვეტი სერვისი. სწორედ ამ უკანასკნელ ნაპრალში მარცხდება ამ ტესტების უმეტესობა ისე, რომ ვერავინ შეამჩნევს. მოთხოვნა, რომელიც სახელთა სივრციდან გადის და ჰოსტის გადამწყვეტს ეკითხება, აბრუნებს პასუხს, რომელსაც სატესტო გვირაბთან არანაირი კავშირი არ აქვს.
ეს პროცედურა გულისხმობს უკვე მომზადებულ და დამტკიცებულ ორ სატესტო სახელთა სივრცეს მოქმედი გარე კავშირითა და მხარდაჭერილი კლიენტებით. ის არაფერს ქმნის, არაფერს რეგისტრირებს და არცერთ კონფიგურაციას არ ცვლის. ცალკე ვირტუალური მანქანები რჩება პატიოსან არჩევნად, როცა კლიენტს სრული სამუშაო მაგიდის სესია სჭირდება ან მის გარეთ მუშაობაზე უარს ამბობს.
დააფიქსირეთ მოლოდინი პირველ გაშვებამდე
თითოეული კონტექსტისთვის გადაწყვიტეთ, როგორ გამოიყურება წარმატება: გადამწყვეტი, სერვისის სახელი, მოსალოდნელი მისამართი და ქცევა, რომელიც გვირაბის ვარდნისასაა საჭირო. შეინახეთ ეს დაგეგმილი მნიშვნელობები საკუთარ სვეტში, რადგან გეგმისა და დაკვირვების შემრევი ჩანაწერი დროის ნიშნის მქონე გამონაგონია. ქვემოთ მოცემული სია არის ის ფორმა, რაც ჩანაწერს სჭირდება, და ყოველი სტრიქონი პირველ კავშირამდე უნდა ივსებოდეს.
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
გადამწყვეტის გაყვანილობა იმ ჩანაწერში საკუთარ სტრიქონს იმსახურებს, რადგან სწორედ ეს ველია ყველაზე მეტად მიდრეკილი ტყუილისკენ. სახელთა სივრცეზე მიბმული ფაილები, როგორიცაა /etc/netns/vpn-a/resolv.conf ჩნდება თავიანთ ჩვეულ გზებზე, როცა ბრძანება სახელთა სივრცის შიგნით სრულდება, როგორც აღწერს iproute2-ის ცნობარი სახელთა სივრცეებზე, თუმცა სახელების სერვისის გადართვის კონფიგურაცია და მის მიერ გაშვებული ნებისმიერი ლოკალური გადამწყვეტი მაინც შეიძლება მოთხოვნა უკან ჰოსტისკენ გააწიოს.
თითო გვირაბი ერთდროულად, მეორე გათიშული
დაუკავშირეთ A მისი არსებული მფლობელის მეშვეობით, სანამ B გამორთული რჩება, შემდეგ ადმინისტრაციული კონტექსტიდან შეამოწმეთ პოლიტიკა, მარშრუტები და არჩეული გზა. ქვემოთ მოცემული ბრძანებებიდან სამი მდგომარეობას კითხულობს; მხოლოდ უკანასკნელი უკავშირდება სახელების სერვისს და არც ერთი მათგანი არ აგზავნის აპლიკაციის მოთხოვნას.
sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internalმარშრუტის ძიება პასუხობს დანიშნულების შესახებ ჰიპოთეტურ კითხვას, ამიტომ ვერ აჩვენებს, რომ სერვისი ტრაფიკს იღებს. შეინახეთ მტკიცების ეს ორი სახე ცალკე სვეტებში, რადგან უარყოფილი კავშირის გვერდით ჯანსაღი მარშრუტი რეალური და ჩვეულებრივი შედეგია. შემდეგ გაგზავნეთ ერთი უვნებელი ნებადართული მოთხოვნა ნამდვილი აპლიკაციით, გაშვებული A-ის კონტექსტში, როგორც მისი ჩვეულებრივი არაპრივილეგირებული მომხმარებელი, სერტიფიკატის შემოწმებისა და აპლიკაციის ავთენტიფიკაციის უცვლელად, და ჩაწერეთ შედეგი სერვისის მიერ დანახულ წყაროს მისამართთან ერთად. გათიშეთ A მისი მფლობელის მეშვეობით და გაიმეორეთ მთელი საბაზისო ხაზი B-ისთვის, აღნიშნეთ ყოველი კონფიგურაციის ცვლილება, რომელსაც აკეთებთ, თორემ ორი საბაზისო ხაზი შედარებადი აღარ იქნება.
ორივე ზემოთ, შემდეგ თითო ქვემოთ
სტაბილური მდგომარეობა მარტივი ნაწილია. ორივე გვირაბის დაკავშირებულ მდგომარეობაში გაიმეორეთ თითოეული კონტექსტის ძიება და აპლიკაციის მოთხოვნა, შემდეგ გაწყვიტეთ ერთი გვირაბი და შეამოწმეთ მეორე. ხელახლა დაუკავშირდით საპირისპირო თანმიმდევრობით, როცა კავშირის რიგი თავად არის კითხვა.
sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20ჩაწერა წყვეტს კამათს, რომელსაც აპლიკაციის შედეგი ვერ წყვეტს: ის აჩვენებს, გავიდა მოთხოვნა თქვენ მიერ მოსალოდნელი ინტერფეისიდან თუ სრულიად სხვა რამიდან. ყოველი გადასვლისთვის ჩაწერეთ მფლობელის ქმედება, დროის ნიშანი, მარშრუტის შედეგი, სახელის შედეგი და აპლიკაციის შედეგი. შემდეგ შეამოწმეთ უსაფრთხო დახურვის მოთხოვნა დაზარალებული სახელთა სივრცის შიგნით, რადგან იზოლაცია გამორთვის ღილაკი არ არის. სახელთა სივრცე ორ გვირაბს ჰყოფს; ის ხელს არ უშლის არც ერთ მათგანს ტრაფიკის ტარებაში, როცა მისი პროფილი ამბობს, რომ ტრაფიკი უნდა შეჩერდეს.
რისი თქმა შეუძლია და რისი არ შეუძლია ამ ჩანაწერს
წარმატება ამტკიცებს იმ დაკვირვებებს ამ განლაგებისთვის, ამ ჰოსტზე, იმ დროს. ის არაფერს ამბობს ორ კლიენტზე, რომლებიც ერთ სამუშაო მაგიდის მარშრუტიზაციის ცხრილს იზიარებენ, და არაფერს გამტარუნარიანობაზე, სანამ ორივე გვირაბი დატვირთვას ატარებს. ეს ცალკე კითხვებია ცალკე ტესტებით და შედარება იმდენად კარგია, რამდენადაც კარგია თითოეულ სტრიქონზე მიმაგრებული კონტექსტი.
შეინახეთ წარუმატებლობები ჩანაწერში წარმატებების გვერდით, მონიშნული, რომელი გვირაბი იყო იმ დროს ჩართული. სუფთა გვერდი, რომელიც მალავს მდგომარეობას გაზომვის მომენტში, უარესია ვიდრე მახინჯი, რომელიც აჩვენებს მას. ჩანაწერს მოგვიანებით ხელახლა გამოსაყენებელს კონტექსტი ხდის და არა ქულა.
ერთ მანქანაზე ორი გვირაბი პატიოსნად შეიძლება შევადაროთ, მაგრამ მხოლოდ იმდენ კონტექსტში, რამდენსაც ნამდვილად აკონტროლებდით. ყველაფერი ამის მიღმა სურვილია გვერდით მწვანე ხატულით.