WireGuard LXC-ში თუ VM-ში Proxmox-ზე: სად უნდა იმუშაოს?
WireGuard შეიძლება მუშაობდეს Proxmox-ის ჰოსტზე, კონტეინერში ან VM-ში. გადამწყვეტი ფაქტორებია ბირთვის მესაკუთრეობა, ინტერფეისის კონტროლი და აღდგენა.
WireGuard-ს სჭირდება ზუსტად ერთი ბირთვი, რომელიც ფლობს მის ინტერფეისს, და ეს ფაქტი წყვეტს Proxmox-ზე განთავსების კამათის უმეტეს ნაწილს მანამ, სანამ წარმადობა საუბარში შემოვა. LXC კონტეინერი ჰოსტის ბირთვის სახელთა სივრცის ხედია, ხოლო VM საკუთარ ბირთვს იტვირთავს. ამიტომ სასარგებლო კითხვა არ არის, რომელი ვარიანტია მსუბუქი, არამედ რომელი ბირთვის შეცვლას ხართ მზად და რომელ აღდგენის გზასთან შეგიძლიათ ცხოვრება. უპასუხეთ ამას და ჰოსტის, კონტეინერის თუ VM-ის არჩევანი ჩვეულებრივ თავისით დგება.
LXC სტუმარი ჰოსტის ბირთვის შიგნით მუშაობს
კონტეინერში wireguard-tools-ის დაყენება გაძლევთ სამართავ პროგრამას და არა კერძო ბირთვს. თქვენ მიერ შექმნილი wg0 ინტერფეისი რეგისტრდება ჰოსტის ქსელურ სტეკში და ჩნდება ჰოსტის მოდულების სიაში. ამიტომ კონტეინერს შეუძლია გაიაროს პაკეტების ყველა შემოწმება და მაინც ჩავარდეს პირველ wg ბრძანებაზე, როცა ჰოსტის ბირთვს მოდული აკლია. და Proxmox-ის კონტეინერების საცნობარი აღწერს ამ საერთო ბირთვის მოდელს, ისევე როგორც სახელთა სივრცისა და უფლებების იმ საზღვრებს, რომლებშიც მუშაობთ.
უფლებამოსილება მეორე შეზღუდვაა. ინტერფეისის აწევა და მიმართულებების მიბმა მოითხოვს ქსელის ადმინისტრირების უფლებებს იმ სახელთა სივრცეში, რომელიც ფლობს მას, და არაპრივილეგირებული კონტეინერი ამ უფლებებს ასახავს თავისი მომხმარებლის სახელთა სივრცის მეშვეობით, ნაცვლად იმისა, რომ პირდაპირ ფლობდეს. არასოდეს მიმართოთ სრულ პრივილეგიას როგორც პირველ პასუხს; შეხედეთ, რასაც რეალურად ითხოვენ კონტეინერისგან, და შემდეგ მისცეთ ის.
ჰოსტის ბირთვი ასევე საერთო დამოკიდებულებაა. Proxmox-ის ბირთვის განახლება ერთდროულად ცვლის WireGuard-ის იმპლემენტაციას ყველა კონტეინერის ქვეშ, რაც მოსახერხებელია მანამ, სანამ განახლება და კონტეინერის მოლოდინები არ დაემთხვევა.
ჰოსტი, კონტეინერი, VM: რას ფლობს რეალურად თითოეული განთავსება
ჰოსტზე განთავსება VPN-ს ათავსებს ჰიპერვიზორის საკუთარ ქსელში. მარშრუტები, firewall-ის წესები და გვირაბი ჰოსტის აღდგენის ნაწილი ხდება, და იქაური შეცდომა შეიძლება წაიღოს მართვის ინტერფეისიც. ეს მისაღებია ინფრასტრუქტურული მარშრუტიზაციისთვის ჰოსტზე, რომელსაც კონსოლით აღწევთ, და მტკივნეულია დისტანციურ მანქანაზე ზოლის გარეთ წვდომის გარეშე.
კონტეინერი სერვისს ინახავს შეფუთულ და გადატვირთვად მდგომარეობაში და მაინც სესხულობს ჰოსტის ბირთვს. ის შესაფერისია განზრახ საერთო ბირთვიანი სერვისისთვის და გაძლევთ გადაკეთების პატარა ერთეულს. დამოუკიდებელ ბირთვს არ გაძლევთ, ამიტომ ყველაფერი, რასაც კონკრეტული მოდულის აწყობა სჭირდება, ამ ვარიანტს შორდება.
| Placement | Kernel owner | Typical failure mode |
|---|---|---|
| Proxmox host | Hypervisor | A routing change breaks host management access |
| LXC container | Host kernel, container namespace | Missing capability or missing module at wg0 creation |
| Virtual machine | Guest kernel | Extra maintenance and a second patch cycle |
VM უფრო მეტ მეხსიერებას და კიდევ ერთ სისტემას მოითხოვს გასაპატჩად, სამაგიეროდ გვირაბი იღებს საკუთარ ბირთვს, საკუთარ მარშრუტიზაციის ცხრილს და snapshot-ის საზღვარს. როცა ცუდი ცვლილების შემდეგ სწორედ VPN-ს აბრუნებთ უკან, ეს snapshot ღირს დამატებითი ხარჯის.
სამი პირობა, რომლებიც თქვენ ნაცვლად ირჩევენ
თუ გვირაბს სჭირდება ბირთვის ვერსია ან WireGuard-ის ფუნქცია, რომელსაც Proxmox-ის ჰოსტი არ გვაწვდის, გაჩერდით აქ და გამოიყენეთ VM. ვერ დააყენებთ უფრო ახალ ბირთვს კონტეინერში, და არ უნდა შეცვალოთ ჰიპერვიზორის ბირთვი ერთი სტუმრისთვის.
თუ გვირაბი საიტის კარიბჭეა რეალური LAN პრეფიქსებისთვის, ჰკითხეთ, ვინ ფლობს უკვე დაბრუნების მარშრუტს. კონტეინერს შეუძლია ტრაფიკის მარშრუტიზაცია, მაგრამ მისი ინტერფეისები ჰოსტის სტეკში ზის, ამიტომ ჰოსტი საბოლოოდ კონფიგურაციის ნაწილს ატარებს, დაგეგმეთ ეს თუ არა. ჰოსტზე განთავსება ამაში პატიოსანია; კონტეინერში განთავსება ხშირად არა.
შემდეგ აწონეთ შეცდომის ზემოქმედების რადიუსი. კონტეინერის გადატვირთვა იაფია, VM-ის snapshot-ის აღდგენა პროგნოზირებადი, ხოლო ჰოსტის ქსელის შეკეთებამ შეიძლება მოითხოვოს ფიზიკური ან კონსოლური წვდომა. სწორი არჩევანი ის არის, რომლის უარესი შემთხვევაც ნამდვილად შეგიძლიათ აღადგინოთ იმ საათში, როცა ეს ხდება.
მეოთხე კითხვა იშვიათად არის გადამწყვეტი, მაგრამ ღირს თქმად: სჭირდება თუ არა ჰოსტზე სხვა რამეს გვირაბის ინტერფეისის დანახვა? თუ კი, ჰოსტზე ან კონტეინერში განთავსება ამ ხილვადობას ლოკალურად ინახავს, ხოლო VM გაიძულებთ სტუმარსა და ჰოსტს შორის მარშრუტიზაციას.
დაამტკიცეთ განთავსება სანამ ტრაფიკს მის გავლით გაატარებთ
დაყენების შემდეგ დაადასტურეთ, რომელი ბირთვი ემსახურება რეალურად ინტერფეისს და მიიღო თუ არა კონტეინერმა საკმარისი უფლებამოსილება მის შესანარჩუნებლად:
$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0შემდეგ შეამოწმეთ გადაცემის მხარე ჰოსტიდან, რადგან ხელის ჩამორთმევა მხოლოდ იმას ამტკიცებს, რომ გვირაბი აწეულია. გამოიყენეთ ip route get კლიენტის მისამართისთვის და დაადასტურეთ, რომ შემდეგი ნახტომი და ინტერფეისი ემთხვევა პროექტს, და რომ დაბრუნების გზა არსებობს მოპირდაპირე მხარეს.
დატოვეთ განლაგება წერილობითი მესაკუთრით: რომელი ბირთვი ატარებს იმპლემენტაციას, რომელი სახელთა სივრცე ინახავს ინტერფეისს და რომელი პრეფიქსების გადაცემა შეუძლია კარიბჭეს. ეს ერთი წინადადება უფრო მეტ ინციდენტს აღკვეთს, ვიდრე სამი განთავსების ნებისმიერი შედარება.