Θέλετε να χρησιμοποιήσετε το Linux στη δουλειά, αλλά το εταιρικό σας VPN δεν σας το επιτρέπει; Τότε αυτό το άρθρο μπορεί να βοηθήσει, αν και αυτό δεν είναι σίγουρο. Θα ήθελα να σας προειδοποιήσω εκ των προτέρων ότι δεν καταλαβαίνω καλά τα θέματα διαχείρισης δικτύου, επομένως είναι πιθανό να τα έκανα όλα λάθος. Από την άλλη, είναι πιθανό να μπορώ να γράψω έναν οδηγό με τέτοιο τρόπο ώστε να είναι κατανοητός στους απλούς ανθρώπους, γι' αυτό σας συμβουλεύω να τον δοκιμάσετε.
Το άρθρο περιέχει πολλές περιττές πληροφορίες, αλλά χωρίς αυτή τη γνώση δεν θα μπορούσα να λύσω τα προβλήματα που μου εμφανίστηκαν απροσδόκητα με τη ρύθμιση ενός VPN. Νομίζω ότι όποιος προσπαθήσει να χρησιμοποιήσει αυτόν τον οδηγό θα έχει προβλήματα που δεν είχα εγώ και ελπίζω ότι αυτές οι επιπλέον πληροφορίες θα βοηθήσουν στην επίλυση αυτών των προβλημάτων από μόνοι τους.
Οι περισσότερες από τις εντολές που χρησιμοποιούνται σε αυτόν τον οδηγό πρέπει να εκτελούνται μέσω sudo, το οποίο έχει αφαιρεθεί για λόγους συντομίας. Θυμήσου.
Οι περισσότερες διευθύνσεις IP έχουν συσκοτιστεί σοβαρά, επομένως αν δείτε μια διεύθυνση όπως η 435.435.435.435, πρέπει να υπάρχει κάποια κανονική IP, ειδικά για την περίπτωσή σας.
Έχω το Ubuntu 18.04, αλλά νομίζω ότι με μικρές αλλαγές ο οδηγός μπορεί να εφαρμοστεί και σε άλλες διανομές. Ωστόσο, σε αυτό το κείμενο Linux == Ubuntu.
Cisco Connect
Όσοι χρησιμοποιούν Windows ή MacOS μπορούν να συνδεθούν στο εταιρικό μας VPN μέσω Cisco Connect, το οποίο πρέπει να προσδιορίζει τη διεύθυνση πύλης και, κάθε φορά που συνδέεστε, να εισάγετε έναν κωδικό πρόσβασης που αποτελείται από ένα σταθερό μέρος και έναν κωδικό που δημιουργείται από τον Επαληθευτή Google.
Στην περίπτωση του Linux, δεν μπόρεσα να εκτελέσω το Cisco Connect, αλλά κατάφερα να αναζητήσω στο Google μια σύσταση για χρήση του openconnect, που έγινε ειδικά για να αντικαταστήσει το Cisco Connect.
Ανοίξτε τη σύνδεση
Θεωρητικά, το Ubuntu έχει μια ειδική γραφική διεπαφή για openconnect, αλλά δεν λειτούργησε για μένα. Ίσως είναι προς το καλύτερο.
Στο Ubuntu, το openconnect εγκαθίσταται από τον διαχειριστή πακέτων.
apt install openconnectΑμέσως μετά την εγκατάσταση, μπορείτε να δοκιμάσετε να συνδεθείτε σε ένα VPN
openconnect --user poxvuibr vpn.evilcorp.comΤο vpn.evilcorp.com είναι η διεύθυνση ενός εικονικού VPN
poxvuibr - πλασματικό όνομα χρήστη
Το openconnect θα σας ζητήσει να εισαγάγετε έναν κωδικό πρόσβασης, ο οποίος, να σας υπενθυμίσω, αποτελείται από ένα σταθερό μέρος και έναν κωδικό από τον Επαληθευτή Google και στη συνέχεια θα προσπαθήσει να συνδεθεί στο vpn. Εάν λειτουργεί, συγχαρητήρια, μπορείτε να παραλείψετε με ασφάλεια τη μέση, που είναι πολύ πόνος, και να προχωρήσετε στο σημείο της λειτουργίας openconnect στο παρασκήνιο. Εάν δεν λειτουργεί, τότε μπορείτε να συνεχίσετε. Αν και λειτούργησε κατά τη σύνδεση, για παράδειγμα, από Wi-Fi επισκέπτη στην εργασία, τότε μπορεί να είναι πολύ νωρίς για να χαρείτε, θα πρέπει να προσπαθήσετε να επαναλάβετε τη διαδικασία από το σπίτι.
Πιστοποιητικό
Υπάρχει μεγάλη πιθανότητα να μην ξεκινήσει τίποτα και η έξοδος openconnect θα μοιάζει κάπως έτσι:
POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Certificate from VPN server "vpn.evilcorp.com" failed verification.
Reason: signer not found
To trust this server in future, perhaps add this to your command line:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progressΑπό τη μία πλευρά, αυτό είναι δυσάρεστο, επειδή δεν υπήρχε σύνδεση με το VPN, αλλά από την άλλη πλευρά, ο τρόπος επίλυσης αυτού του προβλήματος είναι, καταρχήν, σαφής.
Εδώ ο διακομιστής μας έστειλε ένα πιστοποιητικό, με το οποίο μπορούμε να προσδιορίσουμε ότι η σύνδεση γίνεται στον διακομιστή της εγγενούς εταιρείας μας και όχι σε έναν κακό απατεώνα και αυτό το πιστοποιητικό είναι άγνωστο στο σύστημα. Και επομένως δεν μπορεί να ελέγξει αν ο διακομιστής είναι πραγματικός ή όχι. Και έτσι, για κάθε περίπτωση, σταματά να λειτουργεί.
Για να συνδεθεί το openconnect στον διακομιστή, πρέπει να του πείτε ρητά ποιο πιστοποιητικό πρέπει να προέρχεται από τον διακομιστή VPN χρησιμοποιώντας το κλειδί —servercert
Και μπορείτε να μάθετε ποιο πιστοποιητικό μας έστειλε ο διακομιστής απευθείας από αυτό που εκτύπωσε το openconnect. Εδώ είναι από αυτό το κομμάτι:
To trust this server in future, perhaps add this to your command line:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progressΜε αυτήν την εντολή μπορείτε να προσπαθήσετε να συνδεθείτε ξανά
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comΊσως τώρα λειτουργεί, τότε μπορείτε να προχωρήσετε στο τέλος. Αλλά προσωπικά, το Ubunta μου έδειξε ένα σύκο με αυτή τη μορφή
POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Connected to HTTPS on vpn.evilcorp.com
XML POST enabled
Please enter your username and password.
POST https://vpn.evilcorp.com/
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 300, Keepalive 30
Set up DTLS failed; using SSL instead
Connected as 192.168.333.222, using SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK answers: File exists
/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf/ Etc / resolv.conf
# Generated by NetworkManager
search gst.evilcorpguest.com
nameserver 127.0.0.53/run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 192.168.430.534
nameserver 127.0.0.53
search evilcorp.com gst.publicevilcorp.comΤο habr.com θα επιλυθεί, αλλά δεν θα μπορείτε να πάτε εκεί. Διευθύνσεις όπως jira.evilcorp.com δεν επιλύονται καθόλου.
Αυτό που συνέβη εδώ δεν μου είναι ξεκάθαρο. Αλλά το πείραμα δείχνει ότι αν προσθέσετε τη γραμμή στο /etc/resolv.conf
nameserver 192.168.430.534τότε οι διευθύνσεις μέσα στο VPN θα αρχίσουν να επιλύονται μαγικά και μπορείτε να τις περπατήσετε, δηλαδή αυτό που ψάχνει το DNS για την επίλυση διευθύνσεων φαίνεται συγκεκριμένα στο /etc/resolv.conf και όχι κάπου αλλού.
Μπορείτε να επαληθεύσετε ότι υπάρχει σύνδεση με το VPN και ότι λειτουργεί χωρίς να κάνετε αλλαγές στο /etc/resolv.conf. Για να το κάνετε αυτό, απλώς εισαγάγετε στο πρόγραμμα περιήγησης όχι το συμβολικό όνομα του πόρου από το VPN, αλλά τη διεύθυνση IP του
Ως αποτέλεσμα, υπάρχουν δύο προβλήματα
- Κατά τη σύνδεση σε ένα VPN, το dns του δεν λαμβάνεται
- όλη η κίνηση περνά μέσω VPN, το οποίο δεν επιτρέπει την πρόσβαση στο Διαδίκτυο
Θα σας πω τι να κάνετε τώρα, αλλά πρώτα λίγο αυτοματισμό.
Αυτόματη εισαγωγή του σταθερού μέρους του κωδικού πρόσβασης
Μέχρι τώρα, πιθανότατα έχετε ήδη εισάγει τον κωδικό πρόσβασής σας τουλάχιστον πέντε φορές και αυτή η διαδικασία σας έχει ήδη κουράσει. Πρώτον, επειδή ο κωδικός πρόσβασης είναι μεγάλος, και δεύτερον, επειδή κατά την εισαγωγή πρέπει να χωρέσετε σε μια καθορισμένη χρονική περίοδο
Η τελική λύση του προβλήματος δεν συμπεριλήφθηκε στο άρθρο, αλλά μπορείτε να βεβαιωθείτε ότι το σταθερό μέρος του κωδικού πρόσβασης δεν χρειάζεται να εισαχθεί πολλές φορές.
Ας υποθέσουμε ότι το σταθερό μέρος του κωδικού πρόσβασης είναι fixedPassword και το τμήμα από τον Επαληθευτή Google είναι 567. Ολόκληρος ο κωδικός πρόσβασης μπορεί να περάσει στο openconnect μέσω τυπικής εισαγωγής χρησιμοποιώντας το όρισμα --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinΤώρα μπορείτε να επιστρέφετε συνεχώς στην τελευταία εντολή που εισαγάγατε και να αλλάξετε μόνο μέρος του Επαληθευτή Google εκεί.
Ένα εταιρικό VPN δεν σας επιτρέπει να σερφάρετε στο Διαδίκτυο.
Γενικά, δεν είναι πολύ άβολο όταν πρέπει να χρησιμοποιήσετε έναν ξεχωριστό υπολογιστή για να μεταβείτε στο Habr. Η αδυναμία αντιγραφής-επικόλλησης από το stackoverfow μπορεί γενικά να παραλύσει την εργασία, επομένως κάτι πρέπει να γίνει.
Πρέπει με κάποιο τρόπο να το οργανώσουμε έτσι ώστε όταν χρειάζεται να αποκτήσετε πρόσβαση σε έναν πόρο από το εσωτερικό δίκτυο, το Linux να πηγαίνει στο VPN και όταν πρέπει να μεταβείτε στο Habr, να πηγαίνει στο Διαδίκτυο.
Το openconnect, μετά την εκκίνηση και τη δημιουργία σύνδεσης με το vpn, εκτελεί ένα ειδικό σενάριο, το οποίο βρίσκεται στο /usr/share/vpnc-scripts/vpnc-script. Ορισμένες μεταβλητές μεταβιβάζονται στο σενάριο ως είσοδος και διαμορφώνει το VPN. Δυστυχώς, δεν μπορούσα να καταλάβω πώς να μοιράσω τις ροές κυκλοφορίας μεταξύ ενός εταιρικού VPN και του υπόλοιπου Διαδικτύου χρησιμοποιώντας ένα εγγενές σενάριο.
Προφανώς, το βοηθητικό πρόγραμμα vpn-slice αναπτύχθηκε ειδικά για ανθρώπους σαν εμένα, το οποίο σας επιτρέπει να στέλνετε κίνηση μέσω δύο καναλιών χωρίς να χορεύετε με ντέφι. Λοιπόν, δηλαδή, θα πρέπει να χορέψεις, αλλά δεν χρειάζεται να είσαι σαμάνος.
Διαχωρισμός κυκλοφορίας με χρήση vpn-slice
Πρώτον, θα πρέπει να εγκαταστήσετε το vpn-slice, θα πρέπει να το καταλάβετε μόνοι σας. Εάν υπάρχουν ερωτήσεις στα σχόλια, θα γράψω μια ξεχωριστή ανάρτηση σχετικά με αυτό. Αλλά αυτό είναι ένα κανονικό πρόγραμμα Python, επομένως δεν θα πρέπει να υπάρχουν δυσκολίες. Έκανα εγκατάσταση χρησιμοποιώντας virtualenv.
Στη συνέχεια, το βοηθητικό πρόγραμμα πρέπει να εφαρμοστεί, χρησιμοποιώντας τον διακόπτη -script, υποδεικνύοντας για openconnect ότι αντί για το τυπικό σενάριο, πρέπει να χρησιμοποιήσετε vpn-slice
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com Το --script περνάει μια συμβολοσειρά με μια εντολή που πρέπει να κληθεί αντί για το σενάριο. ./bin/vpn-slice - διαδρομή προς το εκτελέσιμο αρχείο vpn-slice 192.168.430.0/24 - μάσκα διευθύνσεων για μετάβαση στο vpn. Εδώ, εννοούμε ότι εάν η διεύθυνση ξεκινά με 192.168.430, τότε ο πόρος με αυτήν τη διεύθυνση πρέπει να αναζητηθεί μέσα στο VPN
Η κατάσταση θα πρέπει τώρα να είναι σχεδόν φυσιολογική. Σχεδόν. Τώρα μπορείτε να μεταβείτε στο Habr και μπορείτε να μεταβείτε στον ενδοεταιρικό πόρο μέσω ip, αλλά δεν μπορείτε να μεταβείτε στον ενδοεταιρικό πόρο με συμβολικό όνομα. Εάν καθορίσετε μια αντιστοίχιση μεταξύ του συμβολικού ονόματος και της διεύθυνσης στους κεντρικούς υπολογιστές, όλα θα πρέπει να λειτουργούν. Και δούλεψε μέχρι να αλλάξει η ip. Το Linux μπορεί πλέον να έχει πρόσβαση στο Internet ή στο intranet, ανάλογα με την IP. Αλλά το μη εταιρικό DNS εξακολουθεί να χρησιμοποιείται για τον προσδιορισμό της διεύθυνσης.
Το πρόβλημα μπορεί επίσης να εκδηλωθεί με αυτή τη μορφή - στην εργασία όλα είναι καλά, αλλά στο σπίτι μπορείτε να έχετε πρόσβαση μόνο σε εσωτερικούς εταιρικούς πόρους μέσω IP. Αυτό συμβαίνει επειδή όταν είστε συνδεδεμένοι σε εταιρικό Wi-Fi, χρησιμοποιείται επίσης το εταιρικό DNS και σε αυτό επιλύονται συμβολικές διευθύνσεις από το VPN, παρά το γεγονός ότι εξακολουθεί να είναι αδύνατο να μεταβείτε σε μια τέτοια διεύθυνση χωρίς τη χρήση VPN.
Αυτόματη τροποποίηση του αρχείου hosts
Εάν ζητηθεί ευγενικά το vpn-slice, τότε αφού ανεβάσει το VPN, μπορεί να πάει στο DNS του, να βρει εκεί τις διευθύνσεις IP των απαραίτητων πόρων με τα συμβολικά τους ονόματα και να τα εισαγάγει σε hosts. Μετά την απενεργοποίηση του VPN, αυτές οι διευθύνσεις θα αφαιρεθούν από τους κεντρικούς υπολογιστές. Για να το κάνετε αυτό, πρέπει να περάσετε συμβολικά ονόματα στο vpn-slice ως ορίσματα. Σαν αυτό.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Τώρα όλα πρέπει να λειτουργούν τόσο στο γραφείο όσο και στην παραλία.
Αναζητήστε τις διευθύνσεις όλων των υποτομέων στο DNS που δίνονται από το VPN
Εάν υπάρχουν λίγες διευθύνσεις εντός του δικτύου, τότε η προσέγγιση της αυτόματης τροποποίησης του αρχείου hosts λειτουργεί αρκετά καλά. Αλλά αν υπάρχουν πολλοί πόροι στο δίκτυο, τότε θα χρειάζεται συνεχώς να προσθέτετε γραμμές όπως zoidberg.test.evilcorp.com στο σενάριο zoidberg είναι το όνομα ενός από τους πάγκους δοκιμών.
Αλλά τώρα που καταλαβαίνουμε λίγο γιατί αυτή η ανάγκη μπορεί να εξαλειφθεί.
Εάν, μετά την αύξηση του VPN, κοιτάξετε στο /etc/hosts, μπορείτε να δείτε αυτή τη γραμμή
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Και μια νέα γραμμή προστέθηκε στο resolv.conf. Εν ολίγοις, το vpn-slice καθόρισε με κάποιο τρόπο πού βρίσκεται ο διακομιστής dns για το vpn.
Τώρα πρέπει να βεβαιωθούμε ότι για να μάθουμε τη διεύθυνση IP ενός ονόματος τομέα που τελειώνει σε evilcorp.com, το Linux πηγαίνει στο εταιρικό DNS και αν χρειάζεται κάτι άλλο, τότε στο προεπιλεγμένο.
Έψαξα στο Google για αρκετό καιρό και διαπίστωσα ότι μια τέτοια λειτουργικότητα είναι διαθέσιμη στο Ubuntu out of the box. Αυτό σημαίνει τη δυνατότητα χρήσης του τοπικού διακομιστή DNS dnsmasq για την επίλυση ονομάτων.
Δηλαδή, μπορείτε να βεβαιωθείτε ότι το Linux πηγαίνει πάντα στον τοπικό διακομιστή DNS για διευθύνσεις IP, ο οποίος με τη σειρά του, ανάλογα με το όνομα τομέα, θα αναζητήσει την IP στον αντίστοιχο εξωτερικό διακομιστή DNS.
Για να διαχειριστεί οτιδήποτε σχετίζεται με δίκτυα και συνδέσεις δικτύου, το Ubuntu χρησιμοποιεί το NetworkManager και η γραφική διεπαφή για την επιλογή, για παράδειγμα, συνδέσεων Wi-Fi είναι απλώς μια διεπαφή.
Θα χρειαστεί να ανέβουμε στη διαμόρφωση του.
- Δημιουργήστε ένα αρχείο στο /etc/NetworkManager/dnsmasq.d/evilcorp
διεύθυνση=/.evilcorp.com/192.168.430.534
Δώστε προσοχή στο σημείο μπροστά από το evilcorp. Σηματοδοτεί στο dnsmasq ότι όλοι οι υποτομείς του evilcorp.com πρέπει να αναζητηθούν στο εταιρικό dns.
- Πείτε στον NetworkManager να χρησιμοποιήσει το dnsmasq για ανάλυση ονόματος
Η διαμόρφωση του διαχειριστή δικτύου βρίσκεται στο /etc/NetworkManager/NetworkManager.conf Πρέπει να προσθέσετε εκεί:
[κύριος] dns=dnsmasq
- Επανεκκινήστε το NetworkManager
service network-manager restartΤώρα, αφού συνδεθείτε σε ένα VPN χρησιμοποιώντας openconnect και vpn-slice, η ip θα καθοριστεί κανονικά, ακόμα κι αν δεν προσθέσετε συμβολικές διευθύνσεις στα ορίσματα στο vpnslice.
Πώς να αποκτήσετε πρόσβαση σε μεμονωμένες υπηρεσίες μέσω VPN
Αφού κατάφερα να συνδεθώ στο VPN, ήμουν πολύ χαρούμενος για δύο ημέρες και στη συνέχεια αποδείχθηκε ότι αν συνδεθώ στο VPN εκτός του δικτύου του γραφείου, τότε η αλληλογραφία δεν λειτουργεί. Το σύμπτωμα είναι γνωστό, έτσι δεν είναι;
Η αλληλογραφία μας βρίσκεται στο mail.publicevilcorp.com, που σημαίνει ότι δεν εμπίπτει στον κανόνα στο dnsmasq και η διεύθυνση του διακομιστή αλληλογραφίας αναζητείται μέσω του δημόσιου DNS.
Λοιπόν, το γραφείο εξακολουθεί να χρησιμοποιεί DNS, το οποίο περιέχει αυτήν τη διεύθυνση. Αυτό είναι που σκέφτηκα. Μάλιστα, μετά την προσθήκη της γραμμής στο dnsmasq
διεύθυνση=/mail.publicevilcorp.com/192.168.430.534
η κατάσταση δεν έχει αλλάξει καθόλου. Η ip παρέμεινε η ίδια. Έπρεπε να πάω στη δουλειά.
Και μόνο αργότερα, όταν μπήκα βαθύτερα στην κατάσταση και κατάλαβα λίγο το πρόβλημα, ένας έξυπνος άνθρωπος μου είπε πώς να το λύσω. Ήταν απαραίτητο να συνδεθείτε στον διακομιστή αλληλογραφίας όχι μόνο έτσι, αλλά μέσω VPN
Χρησιμοποιώ το vpn-slice για να περάσω μέσω του VPN σε διευθύνσεις που ξεκινούν με 192.168.430. Και ο διακομιστής αλληλογραφίας όχι μόνο έχει μια συμβολική διεύθυνση που δεν είναι υποτομέας του evilcorp, αλλά δεν έχει επίσης διεύθυνση IP που ξεκινά με 192.168.430. Και φυσικά δεν επιτρέπει σε κανέναν από το γενικό δίκτυο να έρθει κοντά του.
Για να περάσει το Linux μέσω του VPN και στον διακομιστή αλληλογραφίας, πρέπει να το προσθέσετε και στο vpn-slice. Ας υποθέσουμε ότι η διεύθυνση του ταχυδρομείου είναι 555.555.555.555
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 555.555.555.555 192.168.430.0/24" vpn.evilcorp.com Σενάριο για αύξηση του VPN με ένα όρισμα
Όλα αυτά, φυσικά, δεν είναι πολύ βολικά. Ναι, μπορείτε να αποθηκεύσετε το κείμενο σε ένα αρχείο και να το κάνετε αντιγραφή-επικόλληση στην κονσόλα αντί να το πληκτρολογήσετε με το χέρι, αλλά και πάλι δεν είναι πολύ ευχάριστο. Για να διευκολύνετε τη διαδικασία, μπορείτε να τυλίξετε την εντολή σε ένα σενάριο που θα βρίσκεται στο PATH. Και τότε θα χρειαστεί να εισαγάγετε μόνο τον κωδικό που λάβατε από τον Επαληθευτή Google
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Αν βάλετε το σενάριο στο connect~evilcorp~ μπορείτε απλά να γράψετε στην κονσόλα
connect_evil_corp 567987Αλλά τώρα πρέπει να διατηρήσετε την κονσόλα στην οποία εκτελείται το openconnect ανοιχτή για κάποιο λόγο
Εκτελείται openconnect στο παρασκήνιο
Ευτυχώς, οι συντάκτες του openconnect φρόντισαν για εμάς και πρόσθεσαν ένα ειδικό κλειδί στο πρόγραμμα -background, το οποίο κάνει το πρόγραμμα να λειτουργεί στο παρασκήνιο μετά την εκκίνηση. Εάν το εκτελέσετε έτσι, μπορείτε να κλείσετε την κονσόλα μετά την εκκίνηση
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Τώρα απλά δεν είναι σαφές πού πηγαίνουν τα αρχεία καταγραφής. Γενικά, δεν χρειαζόμαστε πραγματικά αρχεία καταγραφής, αλλά ποτέ δεν ξέρεις. Το openconnect μπορεί να τα ανακατευθύνει στο syslog, όπου θα διατηρούνται ασφαλή και ασφαλή. πρέπει να προσθέσετε τον διακόπτη –syslog στην εντολή
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Και έτσι, αποδεικνύεται ότι το openconnect λειτουργεί κάπου στο παρασκήνιο και δεν ενοχλεί κανέναν, αλλά δεν είναι σαφές πώς να το σταματήσετε. Δηλαδή, μπορείτε, φυσικά, να φιλτράρετε την έξοδο ps χρησιμοποιώντας το grep και να αναζητήσετε μια διαδικασία που το όνομα της περιέχει openconnect, αλλά αυτό είναι κατά κάποιο τρόπο κουραστικό. Ευχαριστώ και τους συγγραφείς που το σκέφτηκαν. Το Openconnect έχει ένα κλειδί -pid-file, με το οποίο μπορείτε να δώσετε εντολή στο openconnect να γράψει το αναγνωριστικό διεργασίας του σε ένα αρχείο.
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
--pid-file ~/vpn-pidΤώρα μπορείτε πάντα να σκοτώσετε μια διεργασία με την εντολή
kill $(cat ~/vpn-pid)Εάν δεν υπάρχει διαδικασία, το kill θα καταριέται, αλλά δεν θα κάνει λάθος. Εάν το αρχείο δεν υπάρχει, τότε δεν θα συμβεί τίποτα κακό, ώστε να μπορείτε με ασφάλεια να σκοτώσετε τη διαδικασία στην πρώτη γραμμή του σεναρίου.
kill $(cat ~/vpn-pid)
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
--pid-file ~/vpn-pidΤώρα μπορείτε να ενεργοποιήσετε τον υπολογιστή σας, να ανοίξετε την κονσόλα και να εκτελέσετε την εντολή, περνώντας της τον κωδικό από το Google Authenticator. Η κονσόλα μπορεί στη συνέχεια να καρφωθεί.
Χωρίς VPN-slice. Αντί για υστερόλογο
Αποδείχθηκε πολύ δύσκολο να καταλάβουμε πώς να ζούμε χωρίς VPN-slice. Έπρεπε να διαβάσω και να γκουγκλίσω πολύ. Ευτυχώς, αφού ξοδέψαμε τόσο χρόνο με ένα πρόβλημα, τα τεχνικά εγχειρίδια, ακόμη και το man openconnect, διαβάζονταν σαν συναρπαστικά μυθιστορήματα.
Ως αποτέλεσμα, ανακάλυψα ότι το vpn-slice, όπως το εγγενές σενάριο, τροποποιεί τον πίνακα δρομολόγησης σε ξεχωριστά δίκτυα.
Πίνακας δρομολόγησης
Για να το θέσω απλά, αυτός είναι ένας πίνακας στην πρώτη στήλη που περιέχει τη διεύθυνση από την οποία θέλει να περάσει το Linux και στη δεύτερη στήλη από ποιον προσαρμογέα δικτύου να περάσει σε αυτήν τη διεύθυνση. Στην πραγματικότητα, υπάρχουν περισσότερα ηχεία, αλλά αυτό δεν αλλάζει την ουσία.
Για να δείτε τον πίνακα δρομολόγησης, πρέπει να εκτελέσετε την εντολή διαδρομής ip
default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600
192.168.430.0/24 dev tun0 scope link
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600
192.168.430.534 dev tun0 scope link Εδώ, κάθε γραμμή είναι υπεύθυνη για το πού πρέπει να πάτε για να στείλετε ένα μήνυμα σε κάποια διεύθυνση. Το πρώτο είναι μια περιγραφή του πού πρέπει να ξεκινά η διεύθυνση. Για να καταλάβετε πώς να προσδιορίσετε ότι το 192.168.0.0/16 σημαίνει ότι η διεύθυνση πρέπει να ξεκινά με 192.168, πρέπει να ψάξετε στο google τι είναι η μάσκα διεύθυνσης IP. Μετά το dev υπάρχει το όνομα του προσαρμογέα στον οποίο πρέπει να σταλεί το μήνυμα.
Για το VPN, το Linux δημιούργησε έναν εικονικό προσαρμογέα - tun0. Η γραμμή διασφαλίζει ότι η επισκεψιμότητα για όλες τις διευθύνσεις που ξεκινούν με 192.168 διέρχεται από αυτήν
192.168.0.0/16 dev tun0 scope link Μπορείτε επίσης να δείτε την τρέχουσα κατάσταση του πίνακα δρομολόγησης χρησιμοποιώντας την εντολή διαδρομή -n (Οι διευθύνσεις IP είναι έξυπνα ανώνυμες) Αυτή η εντολή παράγει αποτελέσματα σε διαφορετική μορφή και γενικά καταργείται, αλλά η έξοδος της βρίσκεται συχνά σε εγχειρίδια στο Διαδίκτυο και πρέπει να μπορείτε να τη διαβάσετε.
Το πού πρέπει να ξεκινά η διεύθυνση IP για μια διαδρομή μπορεί να γίνει κατανοητό από το συνδυασμό των στηλών Προορισμός και Μάσκα Genmask. Τα μέρη της διεύθυνσης IP που αντιστοιχούν στους αριθμούς 255 στο Genmask λαμβάνονται υπόψη, αλλά εκείνα όπου υπάρχει 0 δεν λαμβάνονται υπόψη. Δηλαδή, ο συνδυασμός Προορισμού 192.168.0.0 και Genmask 255.255.255.0 σημαίνει ότι εάν η διεύθυνση ξεκινά με 192.168.0, τότε το αίτημα προς αυτήν θα ακολουθήσει αυτήν τη διαδρομή. Και αν ο προορισμός 192.168.0.0 αλλά ο Genmask 255.255.0.0, τότε τα αιτήματα για διευθύνσεις που ξεκινούν με 192.168 θα ακολουθήσουν αυτήν τη διαδρομή
Για να καταλάβω τι κάνει στην πραγματικότητα το vpn-slice, αποφάσισα να εξετάσω τις καταστάσεις των πινάκων πριν και μετά
Πριν ενεργοποιήσετε το VPN ήταν κάπως έτσι
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0Μετά την κλήση του openconnect χωρίς vpn-slice έγινε έτσι
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0Και αφού καλέσετε το openconnect σε συνδυασμό με vpn-slice όπως αυτό
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0Μπορεί να φανεί ότι εάν δεν χρησιμοποιείτε το vpn-slice, τότε το openconnect γράφει ρητά ότι όλες οι διευθύνσεις, εκτός από αυτές που υποδεικνύονται συγκεκριμένα, πρέπει να έχουν πρόσβαση μέσω vpn.
Ακριβώς εδώ:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Εκεί, δίπλα, υποδεικνύεται αμέσως μια άλλη διαδρομή, η οποία πρέπει να χρησιμοποιηθεί εάν η διεύθυνση που προσπαθεί να περάσει το Linux δεν ταιριάζει με καμία μάσκα από τον πίνακα.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Είναι ήδη γραμμένο εδώ ότι σε αυτήν την περίπτωση πρέπει να χρησιμοποιήσετε έναν τυπικό προσαρμογέα Wi-Fi.
Πιστεύω ότι η διαδρομή VPN χρησιμοποιείται επειδή είναι η πρώτη στον πίνακα δρομολόγησης.
Και θεωρητικά, εάν αφαιρέσετε αυτήν την προεπιλεγμένη διαδρομή από τον πίνακα δρομολόγησης, τότε σε συνδυασμό με το dnsmasq openconnect θα πρέπει να διασφαλιστεί η κανονική λειτουργία.
προσπάθησα
route del defaultΚαι όλα λειτούργησαν.
Δρομολόγηση αιτημάτων σε διακομιστή αλληλογραφίας χωρίς vpn-slice
Αλλά έχω επίσης έναν διακομιστή αλληλογραφίας με τη διεύθυνση 555.555.555.555, στον οποίο χρειάζεται επίσης πρόσβαση μέσω VPN. Η διαδρομή προς αυτό πρέπει επίσης να προστεθεί χειροκίνητα.
ip route add 555.555.555.555 via dev tun0Και τώρα όλα είναι καλά. Έτσι, μπορείτε να κάνετε χωρίς vpn-slice, αλλά πρέπει να γνωρίζετε καλά τι κάνετε. Τώρα σκέφτομαι αν θα προσθέσω στην τελευταία γραμμή του εγγενούς σεναρίου openconnect για να αφαιρέσω την προεπιλεγμένη διαδρομή και να προσθέσω μια διαδρομή για το mailer μετά τη σύνδεση στο vpn, έτσι ώστε να υπάρχουν λιγότερα κινούμενα μέρη στο ποδήλατό μου.
Πιθανώς, αυτή η ακόλουθη λέξη θα ήταν αρκετή για να καταλάβει κάποιος πώς να ρυθμίσει ένα VPN. Αλλά ενώ προσπαθούσα να καταλάβω τι και πώς να κάνω, διάβασα πάρα πολλούς τέτοιους οδηγούς που λειτουργούν για τον συγγραφέα, αλλά για κάποιο λόγο δεν λειτουργούν για μένα, και αποφάσισα να προσθέσω εδώ όλα τα κομμάτια που βρήκα. Θα ήμουν πολύ χαρούμενος για κάτι τέτοιο.
Πηγή: www.habr.com