აპლიკაცია ინტერფეისზე მიბმულია? მისი VPN გზა ნაგულისხმევი არ არის

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

სამი განსხვავებული მიბმა, სამი განსხვავებული ეფექტი

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

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

დაადგინეთ, რას აყენებს აპლიკაცია სინამდვილეში

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

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

პოლიტიკის მარშრუტიზაცია კითხულობს წყაროს

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

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

გაყოფილი გვირაბი და დამხმარე პროცესები

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

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

შეამოწმეთ აპლიკაციის საკუთარი გზა

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

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