სრული გვირაბი თუ ბოლო წერტილის მარშრუტი: VPN სერვერის ხელმისაწვდომად შენარჩუნება
გვირაბი გადის იმ ქსელზე, რომელსაც ის ცვლის. შეადარეთ ჰოსტის მარშრუტის გამონაკლისი აპლიკაციის დონის სოკეტის ნიშანს და გაიგეთ, როდის ფუჭდება თითოეული.
დაამატეთ ნაგულისხმევი მარშრუტი გვირაბის გავლით და თავად გვირაბის პაკეტები მას გაჰყვება. ცხრილი მაშინ შეიცავს წესს, რომელიც თავის თავს ამარცხებს. სერვერთან დაშიფრული კავშირი ცდილობს იმ კავშირის შიგნით გავლას, რომლის დამყარებასაც ცდილობს.
ორი მექანიზმი ხელს უშლის ამ მარყუჟს. ერთი ჩანს მარშრუტიზაციის ცხრილში, მეორე აპლიკაციის შიგნით ცხოვრობს.
შიდა და გარე ტრაფიკი სხვადასხვა გადაწყვეტილებაა
აპლიკაციის პაკეტი შედის ვირტუალურ ინტერფეისში და ინკაფსულირდება. შედეგია ახალი პაკეტი, მიმართული სერვერის საჯარო მისამართზე. ამ პაკეტს სჭირდება მარშრუტი ფიზიკურ ქსელში, რადგან მისი არც ერთი ნაწილი არ უნდა შევიდეს გვირაბში.
ორივე მარშრუტიზაციის გადაწყვეტილებაა და მხოლოდ პირველი ეკუთვნის გვირაბს. როცა კლიენტი აყენებს ნაგულისხმევ მარშრუტს, რომელიც სერვერსაც ფარავს, გარე პაკეტიც იჭერს.
სიმპტომები მყისიერი და სრულია. ხელის ჩამორთმევა სრულდება და შემდეგ არაფერი მიედინება, ან კავშირი წყდება იმ წამს, როცა მარშრუტი დამონტაჟდება. ორივე შემთხვევაში keepalive ვეღარ გავა.
პირველი ვარიანტი: ჰოსტის მარშრუტი ბოლო წერტილისთვის
პირდაპირი მიდგომა ამატებს მარშრუტს სერვერის მისამართისთვის საწყისი კარიბჭის გავლით. მას ერთი სტრიქონი სჭირდება. ის ხილვადია ყველასთვის, ვინც ცხრილს კითხულობს. ასევე ადვილია მისი ახსნა ცვლილების ჩანაწერში.
მისი სისუსტე ჩნდება მაშინ, როცა ქვეშმდებარე გზა იცვლება. შენახული მარშრუტი ასახელებს კარიბჭეს და ინტერფეისს ძველი ქსელიდან. Wi-Fi-ის შეცვლის შემდეგ ეს კარიბჭე შეიძლება აღარ არსებობდეს, და მარშრუტი უკან რჩება, სწორად გამოიყურება და არაფერს აკეთებს.
# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7
# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0
# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7
ჰოსტის სახელი ამას ართულებს. თუ ბოლო წერტილი სახელია, რომელიც რამდენიმე მისამართში იხსნება, გამონაკლისმა უნდა დაფაროს რეალურად გამოყენებული მისამართი. მოგვიანებით ძიებამ შეიძლება დააბრუნოს ის, რაც მარშრუტს არასდროს დაუფარავს.
მეორე ვარიანტი: სოკეტის დაცვა
სხვა მიდგომა მარშრუტიზაციის ცხრილს არასდროს ეხება. კლიენტი ნიშნავს ან იცავს სოკეტს, რომელიც გვირაბს ატარებს, ამიტომ ოპერაციული სისტემა პოლიტიკის მიხედვით ამ სოკეტის ტრაფიკს გვირაბის გარეთ აგზავნის. Android ამ მექანიზმს პირდაპირ აძლევს VPN აპლიკაციებს. დესკტოპის კლიენტები ეკვივალენტებს ფაირვოლის ნიშნებით ან მოწყობილობაზე მიბმის გამოძახებებით ახორციელებენ.
უპირატესობა ისაა, რომ გამონაკლისი მიჰყვება კავშირს და არა შენახულ კარიბჭეს. ქსელის ცვლილება გადაწერს ქვეშმდებარე გზას და დაცული სოკეტი მასთან ერთად მოძრაობს, რადგან არასდროს ყოფილა მიმაგრებული მისამართზე. მარშრუტების ცხრილი სუფთა რჩება.
ფასი ხილვადობაა. მარშრუტიზაციის ცხრილში არაფერი აჩვენებს გამონაკლისს, ამიტომ ჰოსტის მარშრუტის მაძიებელი რეცენზენტი ვერაფერს პოულობს და შეიძლება დაასკვნას, რომ დიზაინი საშიშია. დაცვა ცხოვრობს კლიენტის კოდში და იმ პოლიტიკის წესებში, რომლებსაც ეს კოდი აყენებს.
არჩევანი მათ შორის
აირჩიეთ სოკეტის დონის მექანიზმი, როცა კლიენტი მას მხარს უჭერს, რადგან ის უძლებს ქსელის ცვლილებებს, რომლებიც მიმაგრებულ მარშრუტს ამტვრევს. აირჩიეთ ჰოსტის მარშრუტი, როცა გამონაკლისი სხვა ხელსაწყოებისთვის ხილვადი უნდა იყოს, ან როცა კლიენტი უკეთესს არაფერს გვთავაზობს.
არც ერთი მექანიზმი არ აუქმებს იმ აუცილებლობას, რომ სერვერის მისამართი საერთოდ ხელმისაწვდომი იყოს. კერძო კარიბჭეს აქვს საჯარო მოსმენის მისამართი და სწორედ ის უნდა დარჩეს გვირაბის გარეთ. მის უკან არსებული შიდა ქსელები ხელმისაწვდომი ხდება მხოლოდ მას შემდეგ, რაც გვირაბი არსებობს.
რაც არ უნდა აირჩიოთ, შეინახეთ ის კომპონენტთან, რომელიც ფლობს გვირაბს. ხელით დამატებული მოხეტიალე ჰოსტის მარშრუტი მუშაობს შემდეგ ქსელამდე და შემდეგ ხვალინდელ იდუმალ შეფერხებად იქცევა.