VPN ჩართულია, VM მიუწვდომელია? მარშრუტი, სავარაუდოდ, არასდროს ყოფილა პრობლემა

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

Host-only ქსელი არის პროგრამული ქსელი, რომელსაც ჰოსტი ფლობს და თავის სტუმრებს უზიარებს, ნებისმიერი ფიზიკური კავშირისგან დამოუკიდებლად. VPN კლიენტის საკუთარ ინტერფეისში არაფერი ცვლის ამ ქსელს, ამიტომ სანამ შეეხებით, გაარკვიეთ, ოთხი ფენიდან რომელი რეალურად ჩავარდა.

მარშრუტი ჩვეულებრივ ჯერ კიდევ ლოკალურია

ჰკითხეთ ბირთვს და არა მარშრუტიზაციის ცხრილის პირველ გვერდს. Linux-ში ip route get 192.168.56.10 იუწყება ზუსტ მარშრუტს, ინტერფეისს და წყაროს მისამართს, რომლებიც გამოყენებული იქნებოდა, რაც განსხვავებული პასუხია ნაგულისხმევი მარშრუტის წაკითხვისა და გამოცნობისგან. თუ გამომავალი ასახელებს host-only ინტერფეისს, გვირაბი საერთოდ არ მონაწილეობს ამ გზაზე.

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

მარშრუტის არჩევა და პაკეტის დაშვება სხვადასხვა გადაწყვეტილებაა

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

ამიტომ ხარვეზი აპლიკაციის მხრიდან იდენტურად გამოიყურება, როგორც მარშრუტიზაციის პრობლემა, ხოლო კლიენტის მხრიდან სრულიად განსხვავებულად. თუ ip route get სწორ ინტერფეისს ასახელებს და კავშირი მაინც დროში იწურება, შეწყვიტეთ მარშრუტების რედაქტირება და ნაცვლად ამისა წაიკითხეთ კლიენტის დოკუმენტირებული ლოკალური წვდომის ქცევა. ზოგი კლიენტი ლოკალური ქვექსელებისთვის დაშვებულთა სიას გვთავაზობს, ზოგი ბლოკავს ყველაფერს, რაც გვირაბი არ არის, ზოგი კი მხოლოდ მაშინ ბლოკავს, როცა kill switch ჩართულია.

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

სტუმარს უარის თქმის სამი გზა აქვს

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

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

გაიარეთ ეს სამი სანამ VM-ის ქსელური რეჟიმის შეცვლას განიხილავთ. თითოეული უფრო მცირე ცვლილებაა, ვიდრე სტუმრის კავშირის ხელახლა აგება, და თითოეულს აქვს მკაფიო ტესტი.

რა არის სინამდვილეში ხიდი და რა ღირს ის

ადაპტერის ხიდის რეჟიმზე გადართვა host-only გზის შეკეთება არ არის. ეს გადაწყვეტილებაა სტუმრის სხვა ქსელში, ჩვეულებრივ ფიზიკურ LAN-ში, განთავსების შესახებ, სადაც ის ხილული ხდება ყველასთვის, ვინც იქ ცხოვრობს. ეს შეიძლება ზუსტად იყოს ის, რაც გსურთ. მაგრამ ეს არ არის ის, რასაც საწყისი კონფიგურაცია აკეთებდა.

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

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

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