მარშრუტიზებული თუ ხიდიანი VPN: აირჩიეთ იმის მიხედვით, თუ რას უნდა მიაღწიოს კლიენტმა

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

ორი მოთხოვნა, რომლებიც ბილეთების ფანჯარასთან ერთნაირად გამოიყურება

თანამშრომლის მოთხოვნა სერვისია, IP-ით მისაწვდომი, მოწყობილობიდან, რომელსაც თქვენ არ აკონტროლებთ. ინჟინერის მოთხოვნა არხის დონეზეა: მოწყობილობა მოელის Ethernet კადრებისა და გამაუწყებლო აღმოჩენის დანახვას, და შესაძლოა DHCP იმ სეგმენტიდან, სადაც თავს მიიჩნევს.

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

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

მარშრუტი ვიწროა LAN-ის წევრობაზე

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

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

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

ხიდი ცვლის მიღების კითხვას

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

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

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

ფილტრაცია ორივე ტოპოლოგიაში არსებობს

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

სანამ საზღვარს დაპირდებით, შეამოწმეთ რას უჭერს პლატფორმა რეალურად მხარს:

bridge link show
nft list ruleset

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

დაამტკიცეთ საზღვარი სამი ცდით

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

გაუშვით დაშვებული და უარყოფილი გზა ერთი და იმავე კლიენტიდან და ჩაწერეთ ორივე:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

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