Android 12 και IKEv1 VPN: έκδοση κυκλοφορίας, IKEv2 και εφαρμογές τρίτων

Δύο τηλέφωνα εμφανίζουν και τα δύο Android 12 στις Ρυθμίσεις, και μόνο ένα από αυτά ξεκινά ακόμη το παλιό προφίλ IPsec XAuth που προσφέρει η πύλη σας. Η διαφορά δεν είναι ρύθμιση στην οποία φτάνει ο χρήστης: ο φρουρός που ελέγχει την εγγενή διαδρομή IKEv1 κοιτά το επίπεδο SDK με το οποίο παραδόθηκε η συσκευή, όχι μόνο την έκδοση που τρέχει τώρα. Αυτή η μία λεπτομέρεια καθορίζει αν έχει νόημα μια σύγκριση στόλου, και καθορίζει επίσης ποια από τις τρεις διαδρομές μετάβασης χρειάζεστε πραγματικά.

Δύο τηλέφωνα Android 12 δεν είναι η ίδια δοκιμή

Η αλλαγή στο AOSP που σταμάτησε τις νέες συσκευές να ξεκινούν παλιά προφίλ IKEv1 συγκρίνει το DEVICE_INITIAL_SDK_INT με το Android S, δηλαδή API 31. Στην εγγενή διαδρομή εκκίνησης, ένα κατάλληλο προφίλ προκαλεί αποτυχία μη υποστηριζόμενης λειτουργίας πριν υπάρξει οποιαδήποτε χρήσιμη σύνδεση. Ένα τηλέφωνο που παραδόθηκε με Android 11 και ενημερώθηκε αργότερα περνά ακόμη αυτόν τον φρουρό· ένα μοντέλο που κυκλοφόρησε με Android 12 δεν περνά.

Μπορείτε να διαβάσετε τους δύο αριθμούς σε συσκευή με ενεργή αποσφαλμάτωση:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

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

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

Διαδρομή ένα: κρατήστε την εγγενή στοίβα εκεί που ακόμη τρέχει

Η παλιά στοίβα είναι αυτή που διαβάζει προφίλ IPsec XAuth PSK, IPsec Hybrid RSA και L2TP/IPsec PSK από την οθόνη VPN του συστήματος. Σε συσκευή που παραδόθηκε κάτω από API 31 παραμένει βιώσιμη διαδρομή μετά από αναβάθμιση, γι’ αυτό μια δοκιμή σε παλαιότερη συσκευή μπορεί να πετύχει ενώ μια νέα δεν ξεκινά το ίδιο προφίλ.

Η σύγκριση που μετρά είναι ανά κατηγορία συσκευής, όχι ανά έκδοση Android: καταγράψτε τα μοντέλα του στόλου, διαβάστε τα επίπεδα API κυκλοφορίας τους και χωρίστε τα σε συσκευές που ξεκινούν ακόμη το προφίλ και σε όσες δεν μπορούν. Οτιδήποτε άλλο παράγει πολιτική υποστήριξης που αυτοαναιρείται τη στιγμή που ο χρήστης αγοράζει νέο τηλέφωνο.

Διαδρομή δύο: προφίλ IKEv2 της πλατφόρμας

Το δημόσιο μοντέλο παροχής του Android για IKEv2 είναι άλλο αντικείμενο, όχι μετονομασμένο προφίλ IKEv1. Το API πλατφόρμας για προφίλ IKEv2 ήρθε με το API 30 και περιμένει IKEv2 με τη μέθοδο ταυτοποίησης που προσφέρει η πύλη, συνήθως βάσει πιστοποιητικού ή EAP. Δεν υπάρχει ενσύρματα συμβατή αναβάθμιση από IKEv1 XAuth ή Hybrid σε IKEv2: η πύλη πρέπει να ρυθμιστεί για το νέο πρωτόκολλο και το προφίλ πρέπει να φέρει την αντίστοιχη ταυτότητα.

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

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

Διαδρομή τρία: εφαρμογή πελάτη τρίτου

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

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

Διαλέξτε με βάση το τι μπορεί να προσφέρει η πύλη

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

Δύο σημεία κάνουν το σχέδιο υπερασπίσιμο. Πρώτον, καταγράψτε τον λόγο κάθε εξαίρεσης μαζί με το μοντέλο και το επίπεδο κυκλοφορίας, ώστε ένας ελεγκτής να βλέπει ότι το όριο είναι φρουρός πλατφόρμας και όχι ανεξήγητη προτίμηση. Δεύτερον, αντιμετωπίστε τη μετάβαση ως προγραμματισμένη εργασία: το IKEv1 έχει καταργηθεί στην πορεία προτύπων (RFC 9395), που σημαίνει ότι οι υπόλοιπες συσκευές θα συρρικνώνονται και οι εξαιρέσεις πρέπει να λήγουν μαζί τους.