Κίνηση Docker και VM πίσω από OpenVPN: δρομολόγηση ή επαναρίθμηση;

Ο κεντρικός υπολογιστής περιηγείται μέσω της σήραγγας και το container δίπλα του δεν φτάνει πουθενά. Η δημοσίευση θύρας από container που εκτελεί τον δικό του πελάτη VPN είναι χειρότερη: το αίτημα φτάνει και η απάντηση δεν φεύγει ποτέ. Και τα δύο είναι αποφάσεις δρομολόγησης στον κεντρικό υπολογιστή, και το Docker είναι μόνο ο αγγελιοφόρος.

Τρεις ερωτήσεις καθορίζουν ποια από τις δύο περιπτώσεις βλέπετε, και χρειάζονται περίπου ένα λεπτό.

Δύο βλάβες που φαίνονται ίδιες

Η πρώτη είναι πρόβλημα διαδρομής επιστροφής. Η δημοσιευμένη θύρα μεταφράζεται μέσα στο container, το αίτημα φτάνει, και η απάντηση δρομολογείται από την προεπιλεγμένη διαδρομή του κεντρικού υπολογιστή, την οποία ο πελάτης OpenVPN έχει στρέψει στο tun0. Η απάντηση φεύγει από διεύθυνση που ο απομακρυσμένος ομότιμος δεν περιμένει, και απορρίπτεται. Η δεύτερη είναι σύγκρουση προθεμάτων: η προεπιλεγμένη γέφυρα του Docker κατέχει το 172.17.0.0/16 και μια εταιρική σήραγγα σπρώχνει το ίδιο εύρος.

Η μία διορθώνεται με πίνακα δρομολόγησης, η άλλη με επαναρίθμηση μιας γέφυρας. Το να επεμβαίνετε πριν ξέρετε ποια είναι ποια είναι ο τρόπος να χαλάσετε ένα container που δουλεύει.

Αποφασίστε με τρεις ερωτήσεις

Ερώτηση πρώτη: εξαφανίζεται η βλάβη όταν σταματήσετε το VPN; Αν όλα δουλεύουν με τη σήραγγα κάτω, υποψιαστείτε τη διαδρομή επιστροφής. Ερώτηση δεύτερη: εμφανίζει το ip route show table all το ίδιο πρόθεμα δύο φορές, μία σε γέφυρα και μία στο tun0; Αυτή είναι η σύγκρουση. Ερώτηση τρίτη: η επηρεαζόμενη διεύθυνση είναι container, επισκέπτης NAT ή επισκέπτης σε γέφυρα;

Η τρίτη ερώτηση μετράει γιατί κάθε περίπτωση έχει διαφορετική σωστή διόρθωση, και το να εφαρμόσετε τη λύση του container σε επισκέπτη libvirt σπαταλά ένα βράδυ.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Διαδρομή επιστροφής: πίνακας για μία διεύθυνση πηγής

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

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Κάθε πακέτο του οποίου η πηγή είναι αυτή η διεύθυνση συμβουλεύεται πρώτα τον πίνακα 10, και ο πίνακας 10 το στέλνει στην πύλη της γέφυρας αντί για τη σήραγγα.

Επιβεβαιώστε με ip route get 1.1.1.1 from 172.22.0.3. Η απάντηση πρέπει να ονομάζει τη διεπαφή της γέφυρας, όχι το tun0. Οι κανόνες που προστίθενται έτσι εξαφανίζονται στην επανεκκίνηση, γι' αυτό βάλτε τους στη μονάδα ή στο άγκιστρο δικτύου που κατέχει το container.

Το ίδιο μοτίβο δουλεύει για container WireGuard, όπου και η διαδρομή απάντησης χρειάζεται ρητό κανόνα.

Σύγκρουση προθεμάτων: επαναριθμήστε τη γέφυρα

Ένας πίνακας δρομολόγησης στέλνει ένα πρόθεμα σε ένα μέρος. Αν το VPN σπρώχνει το 172.17.0.0/16 ενώ η γέφυρα του Docker είναι ήδη εκεί, κερδίζει η χαμηλότερη μετρική: το Docker εγκαθιστά τη συνδεδεμένη διαδρομή του με μετρική 0, και η προωθημένη διαδρομή φτάνει με 50. Τότε η σήραγγα φαίνεται χαλασμένη ενώ το Docker συνεχίζει, ή το αντίστροφο, ανάλογα με τη σειρά εγκατάστασης. Επαναριθμήστε τη γέφυρα αντί να παλεύετε με τη μετρική.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

Επανεκκινήστε το Docker μετά την αλλαγή και δημιουργήστε ξανά δίκτυα φτιαγμένα με το παλιό pool. Η αλλαγή της μετρικής μετατοπίζει μόνο τη σύγκρουση στην επόμενη εκκίνηση.

Τα VM χρειάζονται πάλι άλλη απάντηση

Ένας επισκέπτης libvirt στο προεπιλεγμένο δίκτυο NAT κληρονομεί τη δρομολόγηση του κεντρικού υπολογιστή και σταματά να φτάνει έξω μόλις η σήραγγα του κεντρικού υπολογιστή αποκτήσει την προεπιλεγμένη διαδρομή. Η μεταφορά του επισκέπτη σε γέφυρα ή συσκευή macvtap του δίνει τη δική του διαδρομή στο φυσικό δίκτυο. Στο virt-manager προσθέστε υλικό, επιλέξτε Network, ορίστε την πηγή στη συσκευή κεντρικού υπολογιστή macvtap, κρατήστε το virtio ως μοντέλο και μετά απενεργοποιήστε την παλιά διεπαφή NAT.

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

Για έναν επισκέπτη που χρειάζεται μόνο το LAN του κεντρικού υπολογιστή, ο πελάτης του προμηθευτή μπορεί να έχει τον διακόπτη που λείπει: με το Mullvad, mullvad lan set allow αποκαθιστά την τοπική προσβασιμότητα χωρίς να αγγίξει το libvirt. Και όταν ένα container πρέπει να είναι προσβάσιμο μόνο μέσω της σήραγγας, δέστε τη δημοσιευμένη θύρα στη διεύθυνση της σήραγγας, -p 10.8.0.5:8080:8080, αντί να τη δημοσιεύετε σε κάθε διεύθυνση.