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

გამოიყენეთ მისაწვდომი მისამართები

დააყენეთ VM-ის LAN ადაპტერი ამ ქსელისთვის დამტკიცებულ Bridged Adapter რეჟიმზე და მიეცით მისამართი ჩვეულებრივი განაწილების პროცესით. შემდეგ VM ფიზიკურ LAN-ში ჩნდება როგორც ნებისმიერი სხვა ჰოსტი. მისი ნაგულისხმევი მარშრუტი კვლავ უნდა იყენებდეს რეალურ კარიბჭეს, რათა VPN-პარტნიორამდე დაშიფრული ტრანსპორტი ხელმისაწვდომი დარჩეს. არ გამოიყენოთ VirtualBox-ის ნაგულისხმევი NAT მისამართი LAN-ის შემდეგ ნაბიჯად, რადგან ეს მისამართი ვირტუალური NAT-ის უკან ცხოვრობს და არ არის on-link ჰოსტისთვის ან LAN-ის სხვა მანქანებისთვის.

LAN router:          192.168.70.1/24
VirtualBox host:     192.168.70.5/24
VPN gateway VM:      192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool:     10.80.0.0/24

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

გამოაცხადეთ LAN და შემდეგ გადააგზავნეთ

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

dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"

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

დაბრუნების მარშრუტი LAN-ის როუტერზეა

LAN-ის მოწყობილობები პასუხობენ თავიანთი ნაგულისხმევი კარიბჭის გავლით, რომელიც 192.168.70.1-ზე მდებარე LAN როუტერია. ამ როუტერს წარმოდგენა არ აქვს, სად არის 10.80.0.0/24, თუ არ ეტყვიან. დაამატეთ აუზის მარშრუტი როუტერის მხარდაჭერილ მუდმივ კონფიგურაციაში, VM-ის LAN მისამართისკენ მიმართული. მხოლოდ VirtualBox ჰოსტზე დამატება ასწორებს იმ ბილიკებს, რომლებიც ამ ჰოსტს ეკითხებიან, და ეს LAN-ის ყველა მოწყობილობა არ არის.

ip route add 10.80.0.0/24 via 192.168.70.10

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

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

თვალყური ადევნეთ ერთ პაკეტს დასაწყისიდან ბოლომდე

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

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

თუ კლიენტი VM-ს აღწევს, მაგრამ სერვისს არა, ჯერ როუტერის მარშრუტი შეამოწმეთ. თუ სერვისი იღებს მოთხოვნას და კლიენტი პასუხს არასდროს ხედავს, ეჭვმიტანილი დაბრუნების ბილიკია.

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