Vagrant VM ქრება VPN-ის დაკავშირებისას: ვისი მარშრუტი გატყდა

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

უყურეთ მარშრუტს, არა მანქანას

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

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

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

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

წაიკითხეთ ჰოსტის ცხრილი მანამდე და შემდეგ

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

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

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

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

როცა სტუმრის NAT დიაპაზონია დაჯახება

VirtualBox NAT ნაგულისხმევად იყენებს 10.0.2.0/24-ს და გვირაბი, რომელიც იმავე დიაპაზონს უბიძგებს, სტუმარს აიძულებს ეს ტრაფიკი თავის NAT კარიბჭეს გაუგზავნოს, ნაცვლად ნამდვილი დანიშნულებისა. პაკეტი არასდროს ტოვებს ჰოსტს, ამიტომ მეორე მხარის ვერც ერთი firewall-ის ჟურნალი ვერ აჩვენებს მას. Docker Machine-ს იგივე კლასის კონფლიქტი აქვს თავის მხოლოდ-ჰოსტ გეგმაში და ამ გეგმის შეცვლამ შეიძლება მოითხოვოს მანქანის თავიდან შექმნა მისი სერტიფიკატებითურთ.

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

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

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

აღადგინეთ ბილიკი კლიენტთან ბრძოლის გარეშე

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

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

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

შეამოწმეთ შესწორება ორივე მხარეს

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

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

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

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