იყენებს თქვენი VM ჰოსტის VPN-ს? შეამოწმეთ გესტის შიგნიდან

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

ტესტი უნდა გაეშვას გესტის შიგნით და უნდა დაასახელოს, რა გაზომა.

დაიწყეთ გესტის შიგნით და არა ჰოსტის ბრაუზერში

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

ჩაწერეთ რეჟიმი სანამ რამეს შეცვლით, რადგან სწორედ ის განსაზღვრავს, რას ნიშნავს შედეგი.

გაგზავნეთ ერთი მოთხოვნა, რომლის დანიშნულებაც იცით

გამოიყენეთ უწყინარი მოთხოვნა სერვისის მიმართ, რომელიც იუწყება, რა წყაროს მისამართი დაინახა. შემდეგ შეამოწმეთ თავად გესტის მარშრუტიზაციის გადაწყვეტილება ამ დანიშნულებისთვის: ip route get 203.0.113.5 ბეჭდავს ინტერფეისს და შესასვლელს, რომელსაც გესტი გამოიყენებს.

თუ ინტერფეისი გესტის ჩვეულებრივი NIC-ია, ტრაფიკი გესტის შიგნით გვირაბში არ გადის.

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

რეზოლვერი ცალკე შეამოწმეთ

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

ეს ორი ნებისმიერი მიმართულებით შეიძლება განსხვავდებოდეს, და სწორედ ეს განსხვავებაა ხშირად ნამდვილი ბაგი.

systemd ჰოსტზე resolvectl query ასახელებს ინტერფეისს და DNS სერვერს პასუხის უკან. ძველი კონფიგურაციები სერვერს dig გამოსავალში აჩვენებს. ნებისმიერ შემთხვევაში მთავარია დაინახოთ, რომელი სერვერი უპასუხა და არა უბრალოდ, მოვიდა თუ არა პასუხი.

შეამოწმეთ წარუმატებლობის პოლიტიკა და არა მხოლოდ წარმატება

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

გესტი, რომელიც გვირაბის ჩავარდნისას ფიზიკურ NIC-ზე გადადის, ზუსტად იმას აკეთებს, რასაც NAT რეჟიმი უშვებს.

ჩაწერეთ რეჟიმი და არეალი

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

თუ IPv4 გვირაბს გაჰყვა, ასე თქვით. ნუ გაავრცელებთ მტკიცებას IPv6-ზე, სხვა namespace-ზე ან სხვა ქსელში მყოფ სხვა VM-ზე.