Linux-ის ქსელური სახელების სივრცეები VPN-ისთვის: რას არ იზოლირებენ
სახელების სივრცე გადაადგილებს ინტერფეისებს, მარშრუტებსა და სოკეტებს, არა ფაილებს ან ანგარიშებს. აქ ჩანს, რას ფარავს VPN თავის netns-ში და საიდან ჯერ კიდევ გადის ტრაფიკი.
გაუშვით VPN თავისივე სახელების სივრცეში, იქ გაუშვით ერთი აპლიკაცია, და ტრაფიკი მაინც ჰოსტის მარშრუტით გადის. არაფერია გატეხილი: სახელების სივრცე მართავს მხოლოდ იმ პროცესებს, რომლებიც მასში შედიან, და გაჟონვა მოვიდა იმ პროცესიდან, რომელიც არასდროს შესულა. ინტერფეისები, მისამართები, მარშრუტები, ფაირვოლის წესები და სოკეტები არის ის, რასაც სახელების სივრცე ფლობს. ფაილები, ანგარიშები და უკვე მომუშავე სერვისები არა, და სწორედ აქედან მოდის სიურპრიზების უმეტესობა.
რას ფლობს სახელების სივრცე და სად იბადება სოკეტი
გადაიტანეთ ინტერფეისი სახელების სივრცეში და ჰოსტი მას კარგავს; ააგეთ გვირაბი შიგნით და ჰოსტი ვერ ხედავს მას. ეს არის სახელების სივრცით შემოფარგლული VPN-ის მექანიზმი: მოწყობილობა და მისკენ მიმავალი მარშრუტები ცხოვრობენ კონტექსტში, რომელსაც მხოლოდ არჩეული პროცესები აღწევენ. ჰოსტი ინარჩუნებს ნაგულისხმევ მარშრუტს, ამიტომ გარეთ ყველაფერი ხელუხლებელი რჩება.
WireGuard-ისთვის შექმნის კონტექსტი ისევე მნიშვნელოვანია, როგორც მიმდინარე მდებარეობა: UDP სოკეტი მიბმულია იმ სახელების სივრცეში, სადაც ინტერფეისი შეიქმნა, მას შემდეგაც კი, რაც მოწყობილობა სხვაგან გადადის. რომელ მარშრუტიზაციის ცხრილს მიჰყვებიან დაშიფრული პაკეტები, დამოკიდებულია სწორედ ამ დაბადების ადგილზე. როცა სოკეტი რჩება კონტექსტში, სადაც პარტნიორამდე მარშრუტი არ არის, ინტერფეისი ეძებს და ხელის ჩამორთმევა არასდროს გადის. შეამოწმეთ მისი დაბადების ადგილი, შემდეგ მიმდინარე მდებარეობა.
რას არ იზოლირებს სახელების სივრცე
აქ არაფერი არ ჰყოფს ფაილურ სისტემებს, ანგარიშებს ან საიდუმლოებებს, და არც ერთი ეს საზღვარი არ ჩნდება იმიტომ, რომ სახელების სივრცე შექმენით. რეზოლვერის კონფიგურაცია ფაილია, ამიტომ შიგნითა პროცესს მაინც შეუძლია წაიკითხოს პარამეტრი, რომელიც ჰოსტის რეზოლვერზე მიუთითებს, და გაგზავნოს თავისი მოთხოვნა იმ მარშრუტით, რასაც ეს გულისხმობს. აპლიკაცია, რომელიც მოთხოვნას გადასცემს უკვე მომუშავე შუამავალს ან სისტემურ სერვისს, ჩართავს სრულიად სხვა კონტექსტის პროცესს. ორივე მოთხოვნაა, რომელზეც პასუხის გაცემა საზღვარს არასდროს განუზრახავს.
გადაწყვეტა არის თითო ფაილი თითოეული სახელების სივრცისთვის /etc/netns/<name>/resolv.conf-ში, ან მომზადებული ფაილის bind mount, მიმართული შიგნიდან მისაწვდომ რეზოლვერზე. ჰოსტზე /etc/resolv.conf-ის რედაქტირება არაფერს ცვლის იმაში, რასაც სახელების სივრცე ხედავს.
პროცესების განლაგება სწორედ კონტროლია
იზოლაცია, რომელსაც იღებთ, ზუსტად იმ პროცესების იზოლაციაა, რომლებსაც შიგნით უშვებთ. სახელების სივრცის exec დამხმარის მეშვეობით გაშვებული shell და ყველაფერი, რასაც ის წარმოქმნის, შიგნით რჩება; ჰოსტის სესიიდან გაშვებული სამუშაო მაგიდის აპლიკაცია არა. შექმენით კონტექსტი, გადაიტანეთ მოწყობილობა, შემდეგ დაამტკიცეთ ორივე მხარე:
ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show
წაიკითხეთ პირველი wg show სახელების სივრცის შიგნიდან და მეორე ჰოსტიდან, და დაელოდეთ, რომ მათგან მხოლოდ ერთი ჩამოთვლის პარტნიორს. თუ ორივე ასე იქცევა, მოწყობილობა არასდროს გადასულა; თუ არც ერთი, ის სხვაგან წავიდა. როცა გამშვები სერვისების მენეჯერია, unit ფაილია სარედაქტირებელი, და არა სამუშაო მაგიდის მალსახმობი. unit, რომელსაც სახელების სივრცის პარამეტრი აკლია, დემონს ჰოსტის კონტექსტში უშვებს და დიზაინს ჩუმად აუქმებს.
გამოსცადეთ აპლიკაციის კონტექსტიდან
გაუშვით შემოწმება იმავე ბინარული ფაილითა და იმავე მომხმარებლით, რომელსაც აპლიკაცია იყენებს, სახელების სივრცის შიგნით. ჩართეთ DNS და ორივე მისამართის ოჯახი, რადგან IPv6 მარშრუტი, რომელზეც არასდროს გიფიქრიათ, გასვლის ჩვეულებრივი გზაა. თქვენივე shell-იდან ტესტი მხოლოდ იმას ამტკიცებს, რომ თქვენი shell იზოლირებულია.
შემდეგ გაუშვით იგივე შემოწმება ჰოსტზე და დაადასტურეთ, რომ პასუხები განსხვავდება: გვირაბის მისამართი და განზრახული გასასვლელი შიგნით, ჰოსტის მარშრუტი და ოფისის გასასვლელი გარეთ, და რეზოლვერი სახელით. დაარქვით სახელების სივრცეებს განლაგების მიხედვით და არა პროტოკოლის, რათა გასუფთავების სკრიპტმა ორი მათგანი არ აირიოს.
გადაგზავნა, წარუმატებლობის პოლიტიკა და გასუფთავება
შესახვევისთვის ჩართეთ გადაგზავნა განზრახ და გადაწყვიტეთ, რა უნდა მოხდეს, როცა გვირაბი ვარდება. სახელების სივრცე არ ბლოკავს შიგნით დაყენებულ მარშრუტებს, ამიტომ ჰოსტისკენ სარეზერვო მარშრუტი გამოიყენება, თუ შექმნით. ეს პოლიტიკის გადაწყვეტილებაა და უნდა ჩაიწეროს, სანამ შეფერხება გამოსცდის.
ჩაწერეთ სახელების სივრცეების სახელები, ინტერფეისები და ვის ეკუთვნის კონფიგურაცია, რათა გასუფთავებამ მხოლოდ განლაგების შექმნილი წაშალოს. ჰოსტის ქსელის გადატვირთვა უკუბრუნების დროს გასუფთავებას შეფერხებად აქცევს. გვერდი network_namespaces(7) მოკლეა და ღირს წაკითხვად, სანამ ამ გზას დააპროექტებთ.