ერთი NIC თუ ორი? VPN სერვერის ინტერფეისების განლაგების გადაწყვეტა

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

სამი პირობა, რომლებიც ამას წყვეტს

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

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

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

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

როცა სერვისი VPN ჰოსტზე მუშაობს

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

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

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

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

როცა დანიშნულება LAN-ზეა

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

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

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

რატომ არ ქმნის alias მეორე ზონას

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

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

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

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

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

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

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

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