რატომ მალავს სრული გვირაბის VPN თქვენს მარშრუტიზებულ ლოკალურ VLAN-ებს

პარამეტრმა allow local network არაფერი იცის თქვენი როუტერის უკან არსებული VLAN-ების შესახებ. კონკრეტული მარშრუტი ლოკალური კარიბჭის გავლით ინახავს საცავისა და ლაბორატორიის ქვექსელებს ხელმისაწვდომს.

VPN კლიენტში „allow local network“ გადამრთველი ისე ჟღერს, თითქოს შენობაში ყველაფერს ფარავს. პრაქტიკაში ის ჩვეულებრივ რამდენიმე კერძო მისამართის გამონაკლისს ამატებს გვირაბის ნაგულისხმევ მარშრუტს და იქ ჩერდება. თქვენი საცავის VLAN ხელმისაწვდომი რჩება მხოლოდ მაშინ, თუ ამ კონკრეტული პრეფიქსის მარშრუტი გადაურჩება გვირაბის მოსვლას, და ბევრ კლიენტში ეს ასე არ ხდება.

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

რას ფარავს სინამდვილეში allow-local-network

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

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

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

სამუშაო სადგური 192.168.10.20/24-ზე, კარიბჭით 192.168.10.1, ავტომატურად იღებს დაკავშირებულ მარშრუტს 192.168.10.0/24-ისთვის. საცავის VLAN 192.168.20.0/24-ზე სხვა პრეფიქსია, ხელმისაწვდომი მხოლოდ ამ კარიბჭის გავლით, და სამუშაო სადგურს მისთვის მარშრუტი არ აქვს ნაგულისხმევის გარდა. სანამ გვირაბი ამოვა, ჩვეულებრივი ნაგულისხმევი მარშრუტი შემთხვევით საცავის ტრაფიკს 192.168.10.1-ზე აგზავნის და ყველაფერი მუშაობს.

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

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

გამონაკლისი ჩადეთ იმ ცხრილში, რომელიც იმარჯვებს

ერთ მარშრუტიზაციის ცხრილში /24 ამარცხებს /0-ს ან /1-ს ყველაზე გრძელი პრეფიქსის დამთხვევით, ამიტომ ლოკალური კარიბჭის გავლით საცავის VLAN-მდე კონკრეტული მარშრუტი საკმარისია, იმ პირობით, რომ ცხრილი საერთოდ განიხილება. Linux-ში ჩვეულებრივი ფორმა მოკლეა:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

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

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

სახელები და პოლიტიკა მარშრუტებს არ მიჰყვება

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

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

ხელშეკრულება, რომლის გადაცემაც შეგიძლიათ

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

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

გამოსცადეთ ხელშეკრულება ორჯერ: ერთხელ გვირაბის აწეული მდგომარეობით და ერთხელ ჩამოშვებული. თუ ლოკალური გზა მუშაობს მხოლოდ ერთ ამ მდგომარეობაში, გამონაკლისი ჯერ ხელშეკრულება არ არის.

დაკავშირებული სტატიები