Το container Docker δεν είναι προσβάσιμο μέσω VPN; Συγκρίνετε τα υποδίκτυα

Τα container απαντούν στο LAN του γραφείου και μετά σταματούν να απαντούν τη στιγμή που συνδέεται το εταιρικό VPN. Τίποτα μέσα στο container δεν άλλαξε: καμία επανεκκίνηση, καμία ενημέρωση image, καμία αλλαγή ρυθμίσεων. Αυτό που άλλαξε είναι ο πίνακας δρομολόγησης του host, όπου μια διαδρομή που πρόσθεσε η σήραγγα καλύπτει τώρα τη διεύθυνση που έδωσε το Docker. Πριν επεξεργαστείτε ένα υποδίκτυο ή ζητήσετε εξαίρεση από το VPN, βάλτε τα δύο σχέδια διευθύνσεων δίπλα-δίπλα, γιατί οι επιδιορθώσεις κοστίζουν πολύ διαφορετικούς χρόνους.

Διαβάστε τη διαδρομή πριν αλλάξετε τις ρυθμίσεις

Ξεκινήστε από το δίκτυο που έφτιαξε πραγματικά το Docker. Το μπλοκ IPAM είναι το σχέδιο διευθύνσεων και το υποδίκτυο είναι η γραμμή που έχει σημασία:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Το Compose εκχωρεί από προεπιλογή ένα /16 σε κάθε νέο έργο, ώστε δύο υπηρεσίες να χωρούν μέσα σε ένα εύρος 65,536 διευθύνσεων. Ακριβώς αυτό το πλάτος κάνει τις επικαλύψεις συχνές: ένα τυχαία επιλεγμένο /16 είναι αρκετά μεγάλο για να καταπιεί μια τοποθεσία στην οποία φτάνετε μέσω της σήραγγας, και κανείς δεν το προσέχει μέχρι να σηκωθεί η σήραγγα.

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

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

Δύο μορφές απάντησης οδηγούν σε διαφορετικά σημεία. Αν η έξοδος αναφέρει tun0, wg0 ή άλλη συσκευή σήραγγας, ένα πρόθεμα VPN είναι τουλάχιστον εξίσου συγκεκριμένο με τη διαδρομή της γέφυρας και το πακέτο δεν φτάνει ποτέ στο container. Αν εξακολουθεί να αναφέρει τη γέφυρα, ο host μπορεί να φτάσει το container και η βλάβη σας είναι φιλτράρισμα, DNS ή μια διαδρομή επιστροφής που αποτυγχάνει μόνο προς μία κατεύθυνση.

Γιατί η σύγκρουση /16 είναι εύκολο να συμβεί

Το Docker παίρνει δίκτυα γέφυρας από τις ιδιωτικές δεξαμενές και η προεπιλεγμένη δεξαμενή προέρχεται από το μπλοκ 172.16.0.0/12 σε φέτες /16. Τα εταιρικά δίκτυα χρησιμοποιούν συχνά τον ίδιο ιδιωτικό χώρο και ένα VPN απομακρυσμένης πρόσβασης σπρώχνει αυτά τα προθέματα σε κάθε πελάτη που συνδέεται. Όταν και οι δύο πλευρές πιστεύουν ότι κατέχουν το 172.18.0.0/16, ένας πίνακας δρομολόγησης κρατά δύο αντιφατικούς ισχυρισμούς.

Το μήκος του προθέματος αποφασίζει τον νικητή, όχι η σειρά με την οποία εμφανίζονται οι διαδρομές. Μια σήραγγα που σπρώχνει 10.0.0.0/8 δεν κερδίζει μια διαδρομή γέφυρας 172.18.0.0/16, επειδή το /8 είναι λιγότερο συγκεκριμένο. Μια σήραγγα που σπρώχνει 172.18.0.0/16, ή 172.18.5.0/24 μέσα σε αυτό, κερδίζει. Γι' αυτό ένα laptop δουλεύει στο δίκτυο του γραφείου και αποτυγχάνει στο Wi-Fi του ξενοδοχείου με το ίδιο VPN: ο πελάτης λαμβάνει διαφορετικά προθέματα.

Ο ίδιος πίνακας διέπει και την αντίστροφη κατεύθυνση. Ένα container που χρειάζεται έναν εσωτερικό host στη 10.8.4.20 στέλνει το πακέτο στη γέφυρα πύλης του και ο host το δρομολογεί μετά στη σήραγγα. Αυτή η διαδρομή συνήθως δουλεύει επειδή ο host κάνει το NAT, αλλά αποτυγχάνει όταν η εταιρική πλευρά δέχεται μόνο τη διεύθυνση VPN του laptop ή όταν το φιλτράρισμα αντίστροφης διαδρομής πετά την ασύμμετρη απάντηση.

Συγκρίνετε τις τρεις επιδιορθώσεις

Υπάρχουν μόνο τρεις διέξοδοι και διαφέρουν στο ποιος πρέπει να τις εγκρίνει και στο τι σπάει όσο εφαρμόζετε μία.

Η αναρίθμηση είναι η μόνη επιδιόρθωση που μπορείτε να ολοκληρώσετε χωρίς ticket, γι' αυτό τα περισσότερα κείμενα σταματούν εκεί. Είναι φθηνή σε ένα νέο έργο και ακριβή μόλις ένα εργαλείο μετανάστευσης ή ένα αποθηκευμένο string σύνδεσης δείξει σε κυριολεκτική διεύθυνση. Μετρήστε αυτές τις αναφορές πριν επεξεργαστείτε το YAML, όχι μετά.

Η εξαίρεση από τη σήραγγα είναι η πιο καθαρή απάντηση όταν η επικάλυψη βρίσκεται σε εύρος που η εταιρεία σας κατέχει πραγματικά. Είναι επίσης η πιο αργή και είναι άχρηστη για έναν εργολάβο που δεν μπορεί να αλλάξει το προφίλ του πελάτη. Μια δημοσιευμένη θύρα ή ένας μικρός αντίστροφος proxy αποφεύγει τη διαφωνία: ο πελάτης μιλά σε μια διεύθυνση που η σήραγγα δρομολογεί ήδη σωστά και μόνο αυτή η θύρα πρέπει να είναι προσβάσιμη.

Καρφιτσώστε ένα εύρος σκόπιμα

Για ένα μόνο έργο, δηλώστε το υποδίκτυο στο αρχείο compose ώστε το έργο να σταματήσει να τραβά από την κοινή δεξαμενή:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

Πάρτε αυτό το εύρος από ένα μητρώο που τηρεί η ομάδα σας, όχι από ένα παράδειγμα που βρήκατε ψάχνοντας. Ελέγξτε το απέναντι στα προθέματα που σπρώχνει το VPN, τα οικιακά LAN από τα οποία δουλεύουν άνθρωποι και τα άλλα δίκτυα container στον ίδιο host. Μετά σχεδιάστε την επαναδημιουργία, γιατί ένα υπάρχον δίκτυο κρατά το παλιό του υποδίκτυο: docker compose down, μετά up -d. docker network rm αρνείται όσο είναι συνδεδεμένα endpoints, και κάθε ipv4_address καταχώριση στο αρχείο πρέπει να πέφτει μέσα στο νέο εύρος.

Για δίκτυα που δημιουργεί το ίδιο το Docker, ορίστε μια δεξαμενή daemon στο /etc/docker/daemon.json:

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

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

Η γέφυρα Linux και το Docker Desktop αποτυγχάνουν διαφορετικά

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

Το Docker Desktop βάζει τα container πίσω από ένα VM με δικό του NAT. Ο host δεν έχει καθόλου διαδρομή προς τη διεύθυνση του container: φτάνει στην υπηρεσία μέσω μιας δημοσιευμένης θύρας, συνήθως δεσμευμένης στη 127.0.0.1. Ένας πελάτης VPN μπορεί επομένως να σπάσει την υπηρεσία χωρίς καμία επικάλυψη υποδικτύου, είτε εγκαθιστώντας διαδρομή για το εσωτερικό εύρος του VM είτε μπλοκάροντας την κίνηση loopback όσο η σήραγγα είναι συνδεδεμένη. Αν το ip route get στον host αναφέρει ότι δεν υπάρχει διαδρομή για τη διεύθυνση του container, αυτό είναι αναμενόμενο και όχι το σφάλμα.

Η πρακτική συνέπεια είναι πού κοιτάτε πρώτα. Στο Linux, ξεκινήστε από τον πίνακα δρομολόγησης. Στο Desktop, ξεκινήστε από τη δημοσιευμένη θύρα και τους κανόνες firewall του πελάτη VPN και μετά ελέγξτε αν το εσωτερικό υποδίκτυο του VM συγκρούεται με κάτι που σπρώχνει η σήραγγα.

Επαληθεύστε με τη σήραγγα πάνω

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

1. ip route get από τον host, χρησιμοποιώντας την πραγματική διεύθυνση του container.
2. Ένα αίτημα από άλλο container, για να αποδείξετε ότι η ίδια η υπηρεσία είναι υγιής.
3. curl -sv http://127.0.0.1:8080/ από τον πελάτη με τη σήραγγα πάνω, μετά traceroute -n προς τη διεύθυνση του container από ένα μηχάνημα στο LAN.
4. sysctl net.ipv4.conf.all.rp_filter αν το αίτημα φτάνει στον host αλλά η απάντηση εξαφανίζεται.

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