Το προφίλ μας στο Google Plus
1

Proxy commands για το SSH και SOCKS tunneling

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

Κατά νου έχουμε τώρα το πρωτόκολλο SSH και συγκεκριμένα το εργαλείο ssh, από το πακέτο OpenSSH, με το οποίο εγκαθιδρύουμε πανεύκολα ασφαλείς κρυπτογραφημένες συνδέσεις προς απομακρυσμένα μηχανήματα. Θέλουμε πρόσβαση από το σπίτι σ’ ένα μηχάνημά μας στη δουλειά, στο πανεπιστήμιο ή οπουδήποτε αλλού; Με δεδομένο ότι το απομακρυσμένο μηχάνημα δεν εμποδίζεται από firewall, ανοίγουμε ένα τερματικό, πληκτρολογούμε κάτι σαν ssh auser@remote.host.tld, και σε ελάχιστα δευτερόλεπτα έχουμε πλήρη πρόσβαση στο λογαριασμό του χρήστη auser, στο remote.host.tld. Ακόμη κι αν το εν λόγω μηχάνημα δεν είναι προσβάσιμο από το Internet, αν παρέχεται κάποια υπηρεσία VPN προς το απομακρυσμένο δίκτυο τότε συνδεόμαστε πρώτα σ’ αυτή και μετά στο μηχάνημα-προορισμό.

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

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

Απομονωμένο δίκτυο, σχεδόν πάντα βολικό
Φανταστείτε ότι στο Linux workstation στην εργασία σας, έχετε την υπηρεσία του SSH ενεργοποιημένη. Με ή χωρίς σύνδεση στο εταιρικό VPN, από οποιοδήποτε μέρος του πλανήτη –βεβαίως κι από το Διεθνή Διαστημικό Σταθμό– φτάνετε εύκολα στη γραμμή εντολών του εν λόγω workstation. Το hostname του ας είναι isafjordur, το domain στο οποίο ανήκει ας είναι το colder.xyz, ενώ ο χρήστης στο λογαριασμό του οποίου θέλετε να συνδεόσαστε ας έχει username το sub0.

Από κάποιο άλλο μηχάνημά σας με Linux, λοιπόν, σε ένα τερματικό πληκτρολογείτε ssh sub0@isafjordur.colder.xyz και με ασφάλεια συνδεόσαστε στο isafjordur. Αν μάλιστα έχετε μεταφέρει εκεί το δημόσιο κλειδί του τοπικού σας χρήστη, δεν πληκτρολογείτε καν το password του (απομακρυσμένου) sub0. Για τη σύνδεση ίσως πληκτρολογείτε ακόμη λιγότερα, π.χ., κάτι σαν ssh isafjordur, επειδή στο αρχείο ~/.ssh/config του τοπικού σας χρήστη έχετε μια ενότητα (SSH alias) που μοιάζει με την ακόλουθη:

Host isafjordur
    HostName isafjordur.colder.xyz
    Port 22
    User sub0

Όλα καλά, κατανοητά και συνηθισμένα έως εδώ — ή τουλάχιστον έτσι θέλουμε να πιστεύουμε. Τώρα, το isafjordur είναι ένας KVM host, στον οποίο συχνά-πυκνά δημιουργείτε τοπικά εικονικά δίκτυα (libvirt networks). Μέσα σ’ αυτά εντάσσετε μεμονωμένα QEMU/KVM VMs ή ακόμη κι ολόκληρα clusters, για εκπαιδευτικούς λόγους ή και για (regression) testing μετά την εφαρμογή υποψηφίων maintenance updates. Αν το σενάριο που περιγράφουμε άρχισε να μη βγάζει και πολύ νόημα, δεν υπάρχει κανένας λόγος για ανησυχία: το σημαντικό εδώ είναι να έχουμε κατά νου πως στο isafjordur έχετε φτιάξει ένα ή περισσότερα τοπικά δίκτυα, στα VMs των οποίων εσείς και μόνον φτάνετε πανεύκολα αρκεί να ξεκινάτε από το isafjordur.

Ας στρέψουμε την προσοχή μας σε ένα libvirt network με όνομα qbxnet, για το τοπικό domain με όνομα qboxes.here. Χάρη στις κατάλληλες προσθήκες στο /etc/resolv.conf του isafjordur, στα μηχανήματα του qbxnet φτάνουμε χωρίς καν να γνωρίζουμε τα IP τους. Παράδειγμα: σε ένα VM του qbxnet με hostname το leap423 (και, παρεμπιπτόντως, με guest OS το openSUSE 42.3), από το isafjordur συνδεόμαστε στο λογαριασμό του χρήστη userson απλά πληκτρολογώντας ssh userson@leap423.

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

  • Πώς από ένα μηχάνημά στο σπίτι συνδεόμαστε απευθείας σε μηχάνημα κάποιου απομακρυσμένου εσωτερικού δικτύου, στο οποίο πρόσβαση παρέχεται μόνον μέσω κάποιου άλλου –επίσης απομακρυσμένου– host; Προσοχή: Η λύση των δύο διαδοχικών συνδέσεων SSH δεν είναι ούτε ιδανική, ούτε επιθυμητή.

  • Πώς από ένα μηχάνημα στο σπίτι αποκτάμε πρόσβαση στο περιεχόμενο που προσφέρει web server, ο οποίος τρέχει σε μηχάνημα εντός απομακρυσμένου κι απομονωμένου εσωτερικού δικτύου; Ξανά προσοχή: Για λόγους απλότητας ή/και ασφαλείας δεν επιθυμούμε την εισαγωγή κανόνων port forwarding σε κάποιον άλλον host. Επίσης, για λόγους επιδόσεων δεν θέλουμε να τρέξουμε στον απομακρυσμένο host κάποιον web browser, και με X11 forwarding να έχουμε το display στον υπολογιστή στο σπίτι.

Ένα τοπικό δίκτυο σαν το qbxnet είναι σίγουρα βολικό όταν εργαζόμαστε στον physical host που το φιλοξενεί. Σκεφτείτε, για παράδειγμα, ότι μπορούμε να κάνουμε τις δοκιμές μας χωρίς να παράγουμε θόρυβο στο τοπικό δίκτυο που ανήκει το workstation, χωρίς να απασχολούμε DHCP ή/και DNS servers, χωρίς να εισαγάγουμε δυνητικά προβλήματα ασφαλείας κ.ο.κ. Όταν όμως είμαστε σε κάποιο άλλο μηχάνημα, π.χ., στο σπίτι, μήπως το qbxnet είναι κάπως άβολο για να προχωράμε την εργασία μας; Μήπως παραείναι καλά κρυμμένο, για να το πούμε διαφορετικά;

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

Ένα απλό διάγραμμα για το τι έχουμε και τι θέλουμε να πετύχουμε.

Από το μηχάνημα siglufjordur, στο σπίτι, θέλουμε να συνδεόμαστε απευθείας σε ένα κρυμμένο VM εντός του απομακρυσμένου host με όνομα isafjordur, στη δουλειά.

SSH proxy command
Συνοψίζουμε το πρόβλημα: Είμαστε στο μηχάνημά μας στο σπίτι, με FQDN το siglufjordur.home.loc, και θέλουμε έναν τρόπο προκειμένου να συνδεόμαστε μέσω SSH απευθείας στο λογαριασμό του χρήστη userson, στο μηχάνημα leap423.qboxes.here. Το leap423 είναι προσβάσιμο μόνον από το isafjordur.colder.xyz, στο οποίο έχουμε απομακρυσμένη πρόσβαση από το siglufjordur.

Το αρχείο ~/.ssh/config, στον προσωπικό κατάλογο του χρήστη μας στο τοπικό μηχάνημα, φροντίζουμε ώστε να εμπεριέχει τα δύο ακόλουθα SSH aliases:

Host isafjordur
    HostName isafjordur.colder.xyz
    Port 22
    User sub0

Host leap423
    ProxyCommand ssh -q isafjordur -W leap423.qboxes.here:22
    User userson

Αυτά τα δύο SSH aliases είναι ό,τι χρειάζεται το ssh, ώστε να μας συνδέει στο λογαριασμό του userson στο leap423 μέσω του λογαριασμού του sub0 στο isafjordur. Από τη μεριά μας, το μόνο που θα πληκτρολογούμε στον υπολογιστή στο σπίτι είναι ssh leap423. Αν μάλιστα το δημόσιο κλειδί του χρήστη μας είναι στο αρχείο ~/.ssh/authorized_keys του userson, στο leap423, τότε δεν θα χρειάζεται καν να δίνουμε το αντίστοιχο password. Παρατηρήστε εξάλλου το δεύτερο από τα παραπάνω SSH aliases: χάρη στο local DNS resolving που ισχύει στο isafjordur για τα hosts του qboxes.here, απλά καθορίσαμε την ονομαστική διεύθυνση του leap423. Γράψαμε, δηλαδή, το πλήρες FQDN του, που είναι leap423.qboxes.here. Αν από πλευράς isafjordur δεν παρεχόταν DNS resolving για το qboxes.here, τότε αντί για το FQDN θα καθορίζαμε την αριθμητική διεύθυνση IP του leap423 (η οποία στην περίπτωσή μας είναι 10.10.10.230).

Πριν συνεχίσουμε, προσέξτε ξανά τη γραμμή ProxyCommand, στο SSH alias για το leap423. Ίσως το συντακτικό της αρχικά μοιάζει παράξενο, στην πραγματικότητα όμως είναι αρκετά απλό. Στο παράδειγμά μας, σημαίνει: Συνδέσου μέσω SSH στο TCP port 22 του μηχανήματος leap423.qboxes.here, αφού πρώτα πραγματοποιήσεις τη σύνδεση που ορίζεται στο SSH alias ονόματι isafjordur. Α, κι έχε υπόψη ότι στο leap423.qboxes.here θέλουμε σύνδεση στο λογαριασμό του χρήστη με username το userson.

Συνδυασμός με SOCKS tunneling
Για άλλη μια φορά, συνοψίζουμε το πρόβλημα: Είμαστε στο μηχάνημά μας στο σπίτι, με FQDN το siglufjordur.home.loc, και θέλουμε έναν τρόπο ώστε να βλέπουμε το περιεχόμενο που παρέχει ο web server ενός VM με όνομα s5master.qboxes.here. Το s5master είναι προσβάσιμο μόνον από το απομακρυσμένο isafjordur.colder.xyz, στο οποίο έχουμε πρόσβαση από το siglufjordur.

Ξεκινάμε από το οικιακό μηχάνημα, το siglufjordur. Στο αρχείο ~/.ssh/config φροντίζουμε ώστε να υπάρχουν οι ακόλουθες δύο ενότητες (SSH aliases):

Host isafjordur
    HostName isafjordur.colder.xyz
    Port 22
    User sub0

Host s5master
    ProxyCommand ssh -q isafjordur -W s5master.qboxes.here:22
    User root

Πολύ ωραία. Χάρη στα δύο αυτά aliases, από το λογαριασμό μας στο isafjordur συνδεόμαστε στο λογαριασμό του χρήστη root στο s5master, απλά πληκτρολογώντας ssh s5master. Παρεμπιπτόντως, άπαξ και προσθέσουμε το δημόσιο κλειδί του τοπικού μας χρήστη στο αρχείο ~/.ssh/authorized_keys του root στο s5master, τότε κατά την εγκαθίδρυση σύνδεσης δεν θα μας ζητείται καν το password του root.

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

ssh -D 50999 -f -q -C -N s5master

Aν όλα έγιναν σωστά, τότε στο τερματικό μας δεν βλέπουμε τίποτε απολύτως. Γράφοντας όμως ps aux | grep ssh, το αποτέλεσμα που παίρνουμε μοιάζει με το ακόλουθο και φανερώνει ότι κάτι έχει συμβεί.

Εγκαθίδρυση ασφαλούς SOCKS tunnel.

Εγκαθίδρυση SOCKS tunnel από το τοπικό port 50999/TCP προς τον απομακρυσμένο και απομονωμένο host με όνομα s5master, μέσω του απομακρυσμένου host isafjordur.

Γίνεται λοιπόν φανερό ότι έχουμε συνδεθεί στο s5master, αλλά ποια είναι η σημασία όλων αυτών των παραμέτρων που δώσαμε στο ssh; Τι πετύχαμε, αν πετύχαμε κάτι; Ας δούμε πρώτα τις παραμέτρους.

  • -D: Λέμε στο ssh να δημιουργήσει ένα SOCKS tunnel, ξεκινώντας από ένα τοπικό TCP port μεταξύ 1025-65536 (στο παράδειγμά μας καθορίσαμε το port 50999).

  • -f: Η νέα διεργασία (process) περνά στο υπόβαθρο (background), οπότε μετά την εκτέλεση της εντολής συνεχίζουμε να έχουμε κανονικά πρόσβαση στο τερματικό μας. Ακόμη και να το κλείσουμε, η διεργασία θα συνεχίσει να τρέχει — και συνεπώς το SOCKS tunnel να υφίσταται.

  • -q: Δεν επιθυμούμε πληροφοριακά μηνύματα στο τερματικό. Τι να τα κάνουμε; (Όχι, σοβαρά τώρα, δεν τα χρειαζόμαστε.)

  • -C: Ζητάμε τη συμπίεση των δεδομένων πριν μπουν στο τούνελ. Κατ’ αυτόν τον τρόπο συμβάλλουμε στην καλύτερη αξιοποίηση του bandwidth.

  • -N: Λέμε στο ssh ότι μετά τη δημιουργία του τούνελ δεν θέλουμε να στείλουμε κάποια εντολή στο μηχάνημα στην άλλη άκρη.

Με σχετικά απλό τρόπο μόλις εγκαθιδρύσαμε ένα κρυπτογραφημένο κανάλι επικοινωνίας μεταξύ του τοπικού υπολογιστή κι ενός απομακρυσμένου και κρυμμένου host (s5master), μέσω ενός άλλου απομακρυσμένου host (isafjordur). Αυτή τη στιγμή βέβαια δεν έχουμε πρόσβαση στην κονσόλα του s5master, οπότε ποιο είναι το κέρδος μας; Τέλεια ερώτηση — κι εντελώς αναμενόμενη. Το θέμα εδώ, φίλες και φίλοι, είναι ότι υπάρχουν εφαρμογές που έχουν τη δυνατότητα να χρησιμοποιούν SOCKS tunnels προκειμένου να στέλνουν και να λαμβάνουν δικτυακά πακέτα. Μία απ’ αυτές τις εφαρμογές είναι ο Firefox. Αν λοιπόν τον ρυθμίσουμε κατάλληλα, τότε το web browsing από τη συγκεκριμένη εφαρμογή θα γίνεται μέσω του s5master. Ο Firefox θα είναι σαν να βγαίνει στο Internet από τον εν λόγω host, άρα θα έχουμε πρόσβαση και στο περιεχόμενο που σερβίρει ο web server στο s5master! Χωρίς άλλες καθυστερήσεις, πάμε αμέσως να δούμε πώς ρυθμίζουμε τον Firefox ώστε να χρησιμοποιεί το SOCKS tunnel που πριν λίγο δημιουργήσαμε.

Remote DNS και SOCKS tunneling για τον Firefox
Ξεκινάμε σημειώνοντας ότι, στο πλαίσιο του παρόντος άρθρου, δουλέψαμε με την έκδοση 58.0.1 του Firefox. Αρχικά, στη μπάρα διευθύνσεων του browser πληκτρολογούμε about:config και πατάμε το πλήκτρο [Enter]. Θέλουμε μ’ αυτόν τον τρόπο να αποκτήσουμε πρόσβαση στις προχωρημένες (κι εξ ορισμού κρυμμένες) επιλογές της εφαρμογής. Αμέσως θα λάβουμε μια δραματική (και λίγο αστεία) προειδοποίηση, αφού παίζοντας με τις συγκεκριμένες επιλογές είναι πιθανό να κάνουμε περισσότερο κακό παρά καλό. Εμείς βέβαια τώρα ξέρουμε πολύ καλά τι κάνουμε, το ίδιο κι εσείς. Αποφαστιστικά και χωρίς τον παραμικρό δισταγμό, κάνουμε ένα κλικ στο κουμπί I accept the risk.

Η προειδοποίηση πριν την αποκάλυψη των προχωρημένων (κι εξ ορισμού κρυμμένων) ρυθμίσεων του Firefox.

Παίζοντας με τις προχωρημένες (κι εξ ορισμού κρυμμένες) ρυθμίσεις του Firefox, είναι πιθανό να κάνουμε περισσότερο κακό παρά καλό. Αν πάλι ξέρουμε πολύ καλά τι πάμε να κάνουμε, τότε με αποφασιστικότητα πατάμε σ’ αυτό το “I accept the risk”.

Θα εμφανιστεί μία σελίδα με όλες τις κρυμμένες ρυθμίσεις του Firefox. Επειδή είναι καμιά εβδομηνταριά χιλιάδες (ή λίγο λιγότερες), στη θυρίδα Search μπορούμε να πληκτρολογήσουμε μέρος του ονόματος της ρύθμισης κι από κάτω θα εμφανιστούν μόνον οι ρυθμίσεις που στο όνομά τους εμπεριέχουν ό,τι έχουμε γράψει έως αυτή τη στιγμή.

Προκειμένου να περιορίσουμε τον αριθμό των διαθέσιμων κρυμμένων ρυθμίσεων, στη θυρίδα "Search" πληκτρολογούμε μέρος του ονόματος της επιθυμητής ρύθμισης.

Στη θυρίδα “Search” μπορούμε να πληκτρολογήσουμε μέρος του ονόματος της επιθυμητής ρύθμισης κι από κάτω θα εμφανιστούν μόνον οι ρυθμίσεις που στο όνομά τους εμπεριέχουν ό,τι έχουμε γράψει στη θυρίδα.

Θέλουμε να ζητήσουμε από τον Firefox να αγνοεί τους τοπικά ορισμένους name servers, όταν χρησιμοποιεί SOCKS proxy, και να προωθεί τα σχετικά ερωτήματα μέσω του τούνελ. Προς τούτο, στη θυρίδα Search γράφουμε dns. Χωρίς να πατήσουμε [Enter], βλέπουμε ότι η λίστα ρυθμίσεων περιορίζεται από μόνη της. Στρέφουμε την προσοχή μας στη ρύθμιση –ή καλύτερα στην παράμετρο– με όνομα network.proxy.socks_remote_dns. Ο τύπος της είναι boolean, που σημαίνει ότι δέχεται μία από δύο τιμές: εν προκειμένω, είτε την true είτε την false. Η τρέχουσα τιμή αλλάζει με κλικ πάνω στη γραμμή της παραμέτρου. Περιττό να σημειώσουμε ότι θέλουμε να ισχύει network.proxy.socks_remote_dns = true.

Τα DNS requests του Firefox θέλουμε να αποστέλλονται, μέσω του SOCKS tunnel, στον name server του μηχανήματος στην άλλη άκρη του τούνελ.

Τα DNS requests του Firefox θέλουμε να αποστέλλονται, μέσω του SOCKS tunnel, στον name server του μηχανήματος στην άλλη άκρη του τούνελ. Γι’ αυτό και φροντίζουμε ώστε η επιλεγμένη παράμετρος να είναι “true”.

Στη συνέχεια ανοίγουμε την καρτέλα με τις (φανερές) ρυθμίσεις του Firefox. Πάνω κι αριστερά, κάνουμε ένα κλικ στην κατηγορία General. Στο κάτω μέρος της σελίδας, στην ενότητα Network Proxy, πατάμε στο κουμπί Settings. Εμφανίζεται τότε ένα pop-up window, με όνομα Connection Settings. Για το Configure Proxies to Access the Internet επιλέγουμε το Manual proxy configuration. Στη θυρίδα SOCKS Host από κάτω, πληκτρολογούμε localhost. Στη θυρίδα Port, δεξιά, βάζουμε 50999 — ή το port που έχουμε δώσει στην παράμετρο -D του ssh. Για την έκδοση του πρωτοκόλλου SOCKS επιλέγουμε το SOCKS v5. Επικυρώνουμε τις επιλογές μας με ένα κλικ στο κουμπί OK, κάτω δεξιά.

Ρύθμιση του Firefox ώστε να χρησιμοποιεί το SOCKS tunnel μας ως proxy.

Με την προϋπόθεση ότι το SOCKS tunnel προς το απομακρυσμένο host είναι ενεργό, χάρη στις εικονιζόμενες ρυθμίσεις ο Firefox θα χρησιμοποιεί το συγκεκριμένο τούνελ για την επικοινωνία του με τον έξω κόσμο.

Είμαστε έτοιμοι να δούμε το περιεχόμενο που σερβίρει ο web server στην άλλη άκρη του τούνελ. Για το παράδειγμά μας, στην άλλη άκρη έχουμε το μηχάνημα με FQDN s5master.qboxes.here. Επειδή ρυθμίσαμε τον Firefox ώστε να μη χρησιμοποιεί τους τοπικούς name servers αλλά εκείνους στο απομακρυσμένο άκρο του τούνελ, δεν χρειάζεται να γνωρίζουμε την αριθμητική διεύθυνση του s5master. Στη μπάρα διευθύνσεων του browser, λοιπόν, αρκεί να πληκτρολογήσουμε κάτι σαν http://s5master.qboxes.here (ναι, για το παράδειγμά μας χρησιμοποιούμε το απλό HTTP).

Πρόσβαση στο περιεχόμενο που σερβίρει ένας απομακρυσμένος και καλά κρυμμένος web server.

Συνδυάζοντας τη δυνατότητα του ssh για Proxy commands και το SOCKS tunneling, από τον υπολογιστή μας στο σπίτι και μέσω τρίτου host αποκτάμε πρόσβαση στο περιεχόμενο που σερβίρει ο web server ενός απομακρυσμένου κι απομονωμένου host.

Στο πλαίσιο της παρουσίασής μας ο web server στο s5master.qboxes.here σερβίρει το web dashboard του openATTIC, για ένα πειραματικό SUSE Enterprise Storage cluster.

SOCKS tunneling χωρίς SSH Proxy Commands
Αρκετές φορές δεν ενδιαφερόμαστε να φτάνουμε σε κάποιο απομακρυσμένο ή/και κρυφό δίκτυο, θέλουμε όμως έναν ασφαλή τρόπο για να βγαίνουμε στο Internet και την ίδια στιγμή να προστατεύσουμε την ιδιωτικότητά μας. Η καλύτερη λύση σε τέτοιες περιπτώσεις ακούει στο όνομα OpenVPN. (Διαβάστε, παρεμπιπτόντως, πώς μπορείτε να στήσετε τον δικό σας OpenVPN server σε ένα ταπεινό Raspberry Pi.) Για να δουλέψει όμως χρειάζεται να έχει προηγηθεί αρκετή δουλειά στη μεριά του OpenVPN server, ενώ πρέπει να έχουμε και το κατάλληλο software σε κάθε client. Αν όμως διαθέτουμε κάποιο μηχάνημα ή VPS με OpenSSH server, το οποίο βεβαίως είναι προσβάσιμο από το Internet, τότε ένα απλό SOCKS tunnel αποτελεί μια έξυπνη και γρήγορη λύση για το πρόβλημά μας. Υπογραμμίζουμε ότι δεν θα περνάει όλη η δικτυακή κίνηση του υπολογιστή μέσα από το SOCKS tunnel, αλλά μόνο των εφαρμογών που είναι ικανές να χρησιμοποιούν το τούνελ και φυσικά τις έχουμε ρυθμίσει ώστε να το κάνουν. Στις περισσότερες των περιπτώσεων, η μόνη εφαρμογή που θα θέλουμε να ρυθμίζουμε είναι ο web browser. Επίσης, για ένα τέτοιο σενάριο είναι μάλλον απίθανο να συνδεόμαστε στο απομακρυσμένο μηχάνημα μέσω τρίτου μηχανήματος. Μ’ άλλα λόγια, δεν θα υπάρχει η ανάγκη για τα proxy commands του SSH: απλά θα γράφουμε κάτι σαν ssh -D 50999 -f -q -C -N userson@isafjordur.colder.xyz κι αφού το τούνελ εγκαθιδρύεται θα ρυθμίζουμε τον Firefox ώστε να χρησιμοποιεί το localhost:50999 ως SOCKS5 proxy.

Καταστροφή υφιστάμενου SOCKS tunnel
Όταν δεν χρειαζόμαστε άλλο ένα SOCKS tunnel, καλό είναι να το καταστρέφουμε αμέσως. Πληκτρολογώντας στο τερματικό μας ps aux | grep ssh παίρνουμε μια λίστα με τις διεργασίες που έχουν σχέση με το ssh. Αυτή που μας ενδιαφέρει, στο δεξιό της μέρος θα έχει μια εντολή που ξεκινά κάπως έτσι: ssh -D 50999. Το πρώτο πεδίο από αριστερά είναι το όνομα του χρήστη ο οποίος ξεκίνησε τη διεργασία. Ακριβώς στα δεξιά του είναι το πεδίο με το PID της διεργασίας. Αν, π.χ., το PID είναι 7914, τότε για την καταστροφή του τούνελ αρκεί να πληκτρολογήσουμε kill 7914. Επιβεβαιώνουμε πως όλα πήγαν κατ’ ευχήν δίνοντας ξανά ps aux | grep ssh. Τέλος, δεν πρέπει να ξεχνάμε και τον Firefox. Απλά πηγαίνουμε στις ρυθμίσεις του και φροντίζουμε ώστε να μη χρησιμοποιείται το SOCKS tunnel ως proxy.

One Response to “Proxy commands για το SSH και SOCKS tunneling”

  1. palexandri | 04/02/2018 at 15:35

    Πολύ καλό και κατανοητό άρθρο. Well done! Ένας ακόμα τρόπος απομακρυσμένης πρόσβασης υπηρεσιών με χρήση ssh είναι προφανώς και το ssh tunneling. Π.χ. για να έχω πρόσβαση στον web server του leap423 μπορώ να τρέξω κάτι σαν ssh -L 8080:leap423:80 sub0@isafjordur.xyz
    Επίσης συνδυασμός ssh SOCKS και sslh σε VPS μπορεί να κάνει τα περισσότερα corporate firewalls να βάλλουν τα κλάματα. Ίσως αξίζει ένα τέτοιο άρθρο για όσους υποφέρουν πίσω από εταιρικά firewalls.

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων