WireGuard σε LXC ή VM στο Proxmox: πού πρέπει να τρέχει;

Το WireGuard χρειάζεται ακριβώς έναν πυρήνα που να κατέχει τη διεπαφή του, και αυτό το γεγονός λύνει το μεγαλύτερο μέρος της συζήτησης για την τοποθέτηση στο Proxmox πριν μπει καν η απόδοση. Ένα container LXC είναι μια προβολή χώρου ονομάτων του πυρήνα του host, ενώ μια VM εκκινεί τον δικό της. Άρα το χρήσιμο ερώτημα δεν είναι ποια επιλογή είναι ελαφρύτερη, αλλά ποιον πυρήνα είστε πρόθυμοι να τροποποιήσετε και με ποια διαδρομή ανάκτησης μπορείτε να ζήσετε. Απαντήστε σε αυτό και η επιλογή ανάμεσα σε host, container ή VM συνήθως γίνεται μόνη της.

Ένας guest LXC δουλεύει μέσα στον πυρήνα του host

Η εγκατάσταση του wireguard-tools μέσα σε container σας δίνει το πρόγραμμα ελέγχου, όχι ιδιωτικό πυρήνα. Η διεπαφή wg0 που δημιουργείτε καταγράφεται στη στοίβα δικτύου του host και εμφανίζεται στη λίστα μονάδων του host. Γι' αυτό ένα container μπορεί να περάσει κάθε έλεγχο πακέτων και παρ' όλα αυτά να αποτύχει στην πρώτη εντολή wg όταν ο πυρήνας του host δεν έχει τη μονάδα. Και η τεκμηρίωση container του Proxmox καταγράφει αυτό το μοντέλο κοινόχρηστου πυρήνα μαζί με τα όρια χώρου ονομάτων και προνομίων μέσα στα οποία εργάζεστε.

Δεύτερος περιορισμός είναι η εξουσία. Το σήκωμα μιας διεπαφής και η σύνδεση διευθύνσεων απαιτεί δικαιώματα διαχείρισης δικτύου μέσα στον χώρο ονομάτων που την κατέχει, και ένα container χωρίς προνόμια αντιστοιχίζει αυτά τα δικαιώματα μέσω του χώρου ονομάτων χρήστη του αντί να τα κρατά άμεσα. Μην φτάνετε ποτέ σε πλήρη προνόμια ως πρώτη απάντηση· δείτε τι ζητείται πραγματικά από το container και μετά παραχωρήστε το.

Ο πυρήνας του host είναι επίσης κοινόχρηστη εξάρτηση. Μια ενημέρωση πυρήνα του Proxmox αλλάζει την υλοποίηση του WireGuard κάτω από κάθε container ταυτόχρονα, κάτι που είναι βολικό μέχρι μια ενημέρωση και οι προσδοκίες ενός container να διαφωνήσουν.

Host, container, VM: τι κατέχει πραγματικά κάθε τοποθέτηση

Η τοποθέτηση στον host βάζει το VPN στο δικό του δίκτυο του hypervisor. Οι διαδρομές, οι κανόνες firewall και το tunnel γίνονται μέρος της ανάκτησης του host, και ένα λάθος εκεί μπορεί να πάρει μαζί του τη διεπαφή διαχείρισης. Αυτό είναι αποδεκτό για δρομολόγηση υποδομής σε host στον οποίο φτάνετε μέσω κονσόλας, και επώδυνο σε απομακρυσμένο μηχάνημα χωρίς πρόσβαση εκτός ζώνης.

Ένα container κρατά την υπηρεσία συσκευασμένη και επανεκκινήσιμη ενώ δανείζεται ακόμη τον πυρήνα του host. Ταιριάζει σε μια σκόπιμα κοινόχρηστη υπηρεσία πυρήνα και σας δίνει μια μικρή μονάδα για ανοικοδόμηση. Δεν σας δίνει ανεξάρτητο πυρήνα, οπότε ό,τι χρειάζεται συγκεκριμένη κατασκευή μονάδας δείχνει μακριά από αυτή την επιλογή.

Μια VM κοστίζει περισσότερη μνήμη και άλλο ένα σύστημα για patch, και σε αντάλλαγμα το tunnel αποκτά δικό του πυρήνα, δικό του πίνακα δρομολόγησης και ένα όριο snapshot. Όταν το VPN είναι αυτό που επαναφέρετε μετά από μια κακή αλλαγή, αυτό το snapshot αξίζει το επιπλέον κόστος.

Τρεις συνθήκες που επιλέγουν για εσάς

Αν το tunnel χρειάζεται έκδοση πυρήνα ή λειτουργία του WireGuard που ο host του Proxmox δεν παρέχει, σταματήστε εδώ και χρησιμοποιήστε VM. Δεν μπορείτε να εγκαταστήσετε νεότερο πυρήνα σε container, και δεν θα πρέπει να αντικαταστήσετε τον πυρήνα του hypervisor για να ικανοποιήσετε έναν guest.

Αν το tunnel είναι η πύλη της τοποθεσίας για πραγματικά προθέματα LAN, ρωτήστε ποιος κατέχει ήδη τη διαδρομή επιστροφής. Ένα container μπορεί να δρομολογήσει κίνηση, αλλά οι διεπαφές του κάθονται στη στοίβα του host, οπότε ο host καταλήγει να φέρει μέρος της διαμόρφωσης, είτε το σχεδιάσατε είτε όχι. Η τοποθέτηση στον host είναι ειλικρινής γι' αυτό· η τοποθέτηση σε container συχνά δεν είναι.

Έπειτα ζυγίστε την ακτίνα έκρηξης ενός λάθους. Η επανεκκίνηση container είναι φθηνή, η επαναφορά snapshot VM είναι προβλέψιμη, και η επισκευή του δικτύου του host μπορεί να απαιτήσει φυσική ή κονσολική πρόσβαση. Η σωστή επιλογή είναι εκείνη της οποίας τη χειρότερη περίπτωση μπορείτε πραγματικά να ανακτήσετε την ώρα που συμβαίνει.

Ένα τέταρτο ερώτημα σπάνια είναι καθοριστικό αλλά αξίζει να ειπωθεί: χρειάζεται κάτι άλλο στον host να βλέπει τη διεπαφή του tunnel; Αν ναι, η τοποθέτηση στον host ή σε container κρατά αυτή την ορατότητα τοπική, ενώ μια VM σας αναγκάζει να δρομολογείτε ανάμεσα στον guest και τον host.

Αποδείξτε την τοποθέτηση πριν δρομολογήσετε κίνηση μέσα από αυτή

Μετά την εγκατάσταση, επιβεβαιώστε ποιος πυρήνας εξυπηρετεί πραγματικά τη διεπαφή και αν στο container δόθηκε αρκετή εξουσία για να την κρατήσει:

$ 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

Έπειτα ελέγξτε την πλευρά προώθησης από τον host, γιατί μια χειραψία μόνο αποδεικνύει ότι το tunnel είναι πάνω. Χρησιμοποιήστε το ip route get για διεύθυνση πελάτη και επιβεβαιώστε ότι το επόμενο άλμα και η διεπαφή ταιριάζουν με το σχέδιο, και ότι η διαδρομή επιστροφής υπάρχει στην απέναντι πλευρά.

Αφήστε την ανάπτυξη με γραπτό ιδιοκτήτη: ποιος πυρήνας φέρει την υλοποίηση, ποιος χώρος ονομάτων κρατά τη διεπαφή και ποια προθέματα επιτρέπεται να προωθεί η πύλη. Αυτή η φράση αποτρέπει περισσότερα περιστατικά από κάθε σύγκριση μεγεθών των τριών τοποθετήσεων.