Tor onion service मागे SSH, open ports शिवाय VPS

Tor onion service द्वारे SSH मध्ये काय बदलते

Tor onion service द्वारे SSH वापरल्यास कोणत्याही पोर्टवर inbound connection स्वीकारत नसलेल्या VPS चे प्रशासन करता येते. सर्व्हर Tor network शी outbound connection सुरू करतो आणि ते connection उघडे ठेवतो. तुमचे SSH session त्याच connection मधून परत येते. त्यामुळे public IP address वर कोणत्याही सेवेने listen करण्याची गरज राहत नाही.

याचा log वर त्वरित परिणाम दिसतो. Public SSH port असलेल्या मशीनवर scanners कडून दररोज हजारो अयशस्वी password attempts नोंदवल्या जातात. sshd ला onion service मागे ठेवून firewall वर inbound traffic drop केल्यास /var/log/auth.log मध्ये तुम्ही सुरू केलेली sessionsच नोंदवली जातात.

याची किंमत अशी आहे की प्रत्येक admin session च्या मार्गात tor असते. हा userspace daemon आहे. प्रत्येक reboot नंतर login करण्यापूर्वी तो सुरू होऊन bootstrap पूर्ण करणे आवश्यक असते. Port बंद करण्यापूर्वी याचे नियोजन करा. कारण येथे failure mode असा आहे की प्रत्यक्ष प्रवेश करता न येणाऱ्या मशीनचा access गमावला जाऊ शकतो.

काहीही बदल करण्यापूर्वी पुनर्प्रवेशाचा मार्ग तयार करा

SSH वापरण्याची गरज नसलेला पुनर्प्रवेशाचा मार्ग उपलब्ध होईपर्यंत प्रक्रिया सुरू करू नका.

आता आपल्या provider चे console उघडा. Control panel मधील VNC किंवा serial console वापरून त्यात login करा. root password माहीत नसल्यास, प्रथम panel मधून root password reset करा आणि ते कार्यरत असल्याची खात्री करा. आपण कधीही तपासलेले नसलेले console हा recovery path नाही.

खालील क्रम महत्त्वाचा आहे. पुढील पायरी सुरू करण्यापूर्वी प्रत्येक पायरी कार्यरत असल्याची पडताळणी केली जाते. onion route कार्यरत होईपर्यंत port 22 उघडा राहतो.

1. tor install करा आणि त्याचे bootstrap पूर्ण झाल्याची खात्री करा.
2. onion service define करा आणि त्याचा address वाचा.
3. port 22 अजून उघडा असताना onion द्वारे connect करा.
4. client authorisation जोडा आणि पुन्हा connect करा.
5. sshd ला loopback वर bind करा आणि port 22 बंद करा.
6. reboot करा आणि पुन्हा onion द्वारे connect करा.

ही संपूर्ण प्रक्रिया पूर्ण होईपर्यंत सध्याचे SSH session उघडे ठेवा. नवीन connection रोखणारा firewall बदल आधीपासून स्थापित असलेल्या session ला तोडत नाही. त्यामुळे ते तुमचा पहिला rescue मार्ग आहे.

सर्व्हरवर tor स्थापित करा

Ubuntu मध्ये tor स्वतःच्या repository मध्ये उपलब्ध असतो आणि ती build अनेकदा मागे असते. Tor Project च्या repository मध्ये त्यांच्या दस्तऐवजात वर्णन केलेली आवृत्ती उपलब्ध असते. apt repository guide मधील commands वापरून ती जोडा.

sudo apt update
sudo apt install -y apt-transport-https wget gpg
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

/etc/apt/sources.list.d/tor.sources लिहा. Suites तुमचा release codename स्वीकारतो. तो lsb_release -cs दाखवतो (Ubuntu 24.04 वर noble).

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg

sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
sudo journalctl -u tor@default -n 20 --no-pager

Log चा शेवट Bootstrapped 100% (done) ने झाला पाहिजे. त्याखालीच प्रक्रिया अडकली असल्यास tor नेटवर्कपर्यंत पोहोचू शकत नाही. याचे जवळजवळ नेहमीचे कारण outbound firewall rule किंवा चुकीचे system clock असते.

Unit चे नाव दिशाभूल करणारे आहे. सर्व काही व्यवस्थित असतानाही systemctl status tor मध्ये Active: active (exited) दिसते. Debian आणि Ubuntu मध्ये tor ला multi-instance master unit म्हणून package केले जाते. त्या unit चे एकमेव काम वास्तविक instance सुरू करणे असते. Daemon स्वतः tor@default.service म्हणून चालतो. status आणि journalctl साठी हेच नाव वापरा. tor चे start, stop आणि reload या commands प्रत्यक्ष instance पर्यंत पोहोचतात. त्यामुळे sudo systemctl reload tor अपेक्षेप्रमाणे कार्य करते.

port 22 साठी onion service निश्चित करा

/etc/tor/torrc मध्ये दोन ओळी जोडा.

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22

दुसरी ओळ tor ला onion address वरील virtual port 22 स्वीकारून मशीनवरील 127.0.0.1:22 शी जोडण्यास सांगते. Tor loopback द्वारे sshd पर्यंत पोहोचतो. म्हणूनच नंतर sshd ला public address वर listening थांबवता येते.

sudo systemctl reload tor
sudo cat /var/lib/tor/ssh/hostname

यातून .onion नंतर 56 base32 अक्षरे दिसतात. ही अक्षरे service ची encoded public key आहेत. यामध्ये certificate authority किंवा कुठेही name registration नसते.

/var/lib/tor/ssh/ स्वतः तयार करण्याचे काम tor कडे सोपवा. ते चुकीच्या owner ने manually तयार केल्यास किंवा mode 0700 पेक्षा अधिक सैल असल्यास tor ते वापरण्यास नकार देतो आणि journal मध्ये directory चे permissions खूप सैल असल्याचे नोंदवले जाते. त्यातील फाइल्स service ची identity असतात: hs_ed25519_secret_key हाच address आहे. त्या directory चा mode 600 ठेवून backup घ्या आणि प्रत मशीनबाहेर सुरक्षित ठेवा, कारण ती हरवल्यास प्रत्येक client वर नवीन address आणि configuration बदल करावा लागेल.

वर्कस्टेशनवरून कनेक्ट करा

तुमच्या workstation वर tor client आवश्यक आहे. त्यासाठी कोणत्याही configuration ची गरज नाही. Debian किंवा Ubuntu वर तो sudo apt install -y tor netcat-openbsd आहे. त्यानंतर Tor 127.0.0.1:9050 वर SOCKS5 proxy म्हणून listening करतो. SOCKS हा सर्वसाधारण proxy protocol आहे. त्याची version 5 IP address ऐवजी hostname पाठवू शकते. येथे महत्त्वाचा भाग हाच आहे.

OpenSSH मध्ये स्वतःचा SOCKS client नाही. त्यामुळे connection साठी helper program वापरावे लागते. हे ~/.ssh/config मध्ये जोडा.

Host myvps
  HostName xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion
  User admin
  ProxyCommand /usr/bin/nc -X 5 -x 127.0.0.1:9050 %h %p
  ServerAliveInterval 30

-X 5 SOCKS5 निवडते आणि -x 127.0.0.1:9050 local tor कडे निर्देश करते. %h onion name नावाच्या स्वरूपात tor कडे पाठवते. त्यामुळे tor ते network च्या आत resolve करतो. यासाठी OpenBSD netcat असणे आवश्यक आहे. GNU netcat मध्ये -X option नाही आणि तो nc: invalid option -- 'X' सह थांबतो.

ssh myvps

पहिले connection धीमे असते, कारण पुढील कोणतीही प्रक्रिया सुरू होण्यापूर्वी tor circuit तयार करतो. इतर कोणत्याही ठिकाणी करता त्याच पद्धतीने host key fingerprint स्वीकारा. यानंतर नेहमीची SSH key हाताळणी कोणताही बदल न करता लागू होते. Transport बदलला आहे. Authentication बदललेले नाही.

एकदाच वापरायच्या connection साठी config entry वगळू शकता: torsocks ssh admin@xxxxx.onion तेच काम करते.

v3 client authorisation जोडा

सध्या, पत्ता माहीत असलेली कोणतीही व्यक्ती तुमच्या SSH banner पर्यंत पोहोचू शकते आणि अंदाजाने प्रवेश करण्याचा प्रयत्न करू शकते. Onion पत्ते directory system मधून enumerate करता येत नाहीत, त्यामुळे पत्ता secret प्रमाणे काम करतो. मात्र तो नेहमीच्या मार्गांनी उघड होऊ शकतो: shell history किंवा git repository मध्ये commit केलेल्या config files मधून. Client authorisation ही त्रुटी दूर करते. सेवा तिचा descriptor client key ने encrypted स्वरूपात प्रकाशित करते. त्यामुळे पत्ता आणि key यांपैकी फक्त पत्ता असलेली व्यक्ती सेवा शोधूही शकत नाही.

Client वर x25519 key pair तयार करा. हे Tor Project च्या client authorisation guide मधील pipeline आहे. त्यात एक बदल केला आहे.

openssl genpkey -algorithm x25519 -out /tmp/k1.prv.pem
grep -v " PRIVATE KEY" /tmp/k1.prv.pem | base64 -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/k1.prv.key
openssl pkey -in /tmp/k1.prv.pem -pubout | grep -v " PUBLIC KEY" | base64 -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/k1.pub.key

त्या ओळींच्या प्रकाशित आवृत्तीत base64pem -d वापरले आहे. मात्र stock Ubuntu install मध्ये ते उपलब्ध नसते. त्यामुळे command base64pem: command not found सह थांबते. GNU base64 -d त्याच PEM body चे decoding करते. म्हणून ते वापरा.

Server वर public key install करा.

sudo install -d -m 700 -o debian-tor -g debian-tor /var/lib/tor/ssh/authorized_clients
echo "descriptor:x25519:PASTE_PUBLIC_KEY_HERE" | sudo tee /var/lib/tor/ssh/authorized_clients/laptop.auth >/dev/null
sudo chown debian-tor:debian-tor /var/lib/tor/ssh/authorized_clients/laptop.auth
sudo systemctl reload tor

फक्त .auth ने समाप्त होणाऱ्या files वाचल्या जातात. ती file laptop.auth.txt या नावाने save करा. अन्यथा tor कोणताही error न दाखवता ती file दुर्लक्षित करतो आणि पत्ता माहीत असलेल्या कोणालाही सेवा उपलब्ध राहते.

Client वर private key install करा. Ubuntu वर tor daemon debian-tor user म्हणून चालतो आणि तुमच्या home directory मधील files वाचू शकत नाही. त्यामुळे ही directory त्या user ला उपलब्ध असलेल्या ठिकाणी ठेवा.

sudo install -d -m 700 -o debian-tor -g debian-tor /var/lib/tor/onion_auth
echo "ADDRESS_WITHOUT_DOT_ONION:descriptor:x25519:PASTE_PRIVATE_KEY_HERE" | sudo tee /var/lib/tor/onion_auth/myvps.auth_private >/dev/null
sudo chown debian-tor:debian-tor /var/lib/tor/onion_auth/myvps.auth_private
sudo chmod 600 /var/lib/tor/onion_auth/myvps.auth_private

Client च्या /etc/tor/torrc मध्ये ClientOnionAuthDir /var/lib/tor/onion_auth जोडा आणि tor reload करा. त्याऐवजी tor तुमच्या स्वतःच्या user म्हणून चालवत असल्यास, उदाहरणार्थ macOS वरील Homebrew build मध्ये, ClientOnionAuthDir ला mode 0700 असलेल्या ~/.tor/onion_auth कडे निर्देशित करा.

त्या file मधील पत्ता .onion suffix शिवाय असलेले 56 characters आहेत. काम पूर्ण झाल्यावर /tmp/k1.prv.pem आणि /tmp/k1.prv.key delete करा.

आता दोन्ही दिशांनी चाचणी करा. ssh myvps ने पूर्वीप्रमाणे connect झाले पाहिजे. कोणतीही key नसलेल्या machine वरून तोच पत्ता वापरल्यास connection fail झाले पाहिजे. ही failure authorisation सक्रिय असल्याचा पुरावा आहे.

पोर्ट 22 बंद करा, या क्रमाने

सुरुवातीला सुरक्षिततेची तजवीज करा. तुम्ही स्वतःला बाहेर लॉक केल्यास, ही एक command खालील दोन्ही बदल पंधरा मिनिटांनी पूर्ववत करते.

sudo systemd-run --on-active=15m --unit=ssh-rescue \
  /bin/sh -c 'ufw allow 22/tcp; rm -f /etc/systemd/system/ssh.socket.d/override.conf; systemctl daemon-reload; systemctl restart ssh.socket'

onion route अजूनही कार्यरत असल्याची खात्री झाल्यावर sudo systemctl stop ssh-rescue.timer वापरून ती रद्द करा.

त्यानंतर सार्वजनिक address वर sshd चे listening थांबवा. Ubuntu 24.04 मध्ये ssh socket unit द्वारे सक्रिय होते. त्यामुळे sshd_config मधील ListenAddress दुर्लक्षित केले जाते: listening socket चे नियंत्रण sshd कडे नसून ssh.socket कडे असते. तुमची स्थिती कोणती आहे ते तपासा.

systemctl is-enabled ssh.socket

जर त्यातून enabled दिसले, तर sudo systemctl edit ssh.socket चालवा आणि हे जोडा.

[Socket]
ListenStream=
ListenStream=127.0.0.1:22

रिकामे ListenStream= packaged unit कडून वारशाने मिळालेली value काढून टाकते. ही line वगळल्यास सार्वजनिक listener ठेवून दुसरा listener जोडला जातो. कोणतीही स्पष्ट error न देता ही पायरी अयशस्वी होण्याची ही सर्वात सामान्य पद्धत आहे.

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
ss -tlnp | grep ':22'

ss मध्ये 127.0.0.1:22 दिसले पाहिजे आणि 0.0.0.0:22 वर काहीही दिसू नये. ssh.socket disabled असल्यास, ListenAddress 127.0.0.1 /etc/ssh/sshd_config.d/10-onion.conf मध्ये ठेवा, sudo systemctl restart ssh चालवा आणि त्याच ss line ने पुन्हा तपासा. दोन्हीपैकी कोणत्याही प्रकरणात तो output म्हणजे पडताळणीचा पुरावा आहे.

त्यानंतर firewall तपासा. हे VPS वरील ufw rule management आहे. आधी sudo ufw status numbered चालवा आणि त्यात दिसणारा SSH rule delete करा.

sudo ufw status numbered
sudo ufw delete allow OpenSSH
sudo ufw default allow outgoing
sudo ufw default deny incoming
sudo ufw status verbose

outgoing traffic ला परवानगी राहू द्या. Tor relays शी ports 443 आणि 9001 सारख्या ports वर बाहेरून connection करतो. त्यामुळे outbound default-deny policy मुळे tor bootstrapping थांबते आणि त्याच वेळी तुमच्याकडे उरलेला एकमेव प्रवेशमार्गही बंद होतो. बहुतेक providers control panel मध्ये स्वतंत्र network firewall देखील चालवतात. तेथेही 22 बंद करा. अन्यथा ufw काहीही दाखवत असला तरी port reachable राहतो.

या box वर Docker चालत असल्यास, काम पूर्ण झाले असे समजण्यापूर्वी त्याचे published ports तपासा. Docker त्याचे स्वतःचे rules त्याच tables मध्ये लिहिते आणि container ports थेट ufw च्या पुढे publish करते. त्यामुळे ufw deny policy हे संपूर्ण चित्र नाही.

रीबूट केल्याशिवाय त्यावर विश्वास ठेवू नका

systemctl is-enabled tor@default
sudo reboot

पहिल्या command मध्ये सेवा enabled असल्याचे दिसत नसेल, तर रीबूट करण्यापूर्वी sudo systemctl enable tor@default चालवा. दोन मिनिटे प्रतीक्षा करा आणि त्यानंतर ssh myvps चालवा. बूटनंतर Tor ला bootstrap होण्यासाठी वेळ लागतो. त्यामुळे मशीन सुरू झाल्यानंतर काही वेळाने onion address कडून प्रतिसाद मिळू लागतो.

ती सेवा पुन्हा सुरूच होत नसेल, तर console उघडा आणि sudo journalctl -u tor@default -b वाचा. torrc syntax error किंवा directory permission ची समस्या तेथे दिसेल. torrc मधील बदल लागू करण्यापूर्वी त्यांची तपासणीही करू शकता.

sudo -u debian-tor tor --verify-config

WireGuard tunnel च्या तुलनेत याची किंमत

तुमच्या स्वतःच्या VPS वर WireGuard VPN च्या तुलनेत onion service अधिक मंद आणि कमी अंदाज करता येण्यासारखी असते. हा पर्याय स्वीकारण्यापूर्वी त्यातील तडजोडींबाबत स्वतःशी प्रामाणिक रहा.

Latency. Client circuit मध्ये तीन relays असतात आणि service side वर आणखी तीन relays जोडले जातात. त्यामुळे तुमचे keystrokes जगभर यादृच्छिकपणे निवडलेल्या साधारण सहा machines मधून जातात. Interactive typing मध्ये स्पष्ट विलंब जाणवतो आणि file copies मंद असतात. WireGuard मध्ये एक hop असतो. तुमच्या परिस्थितीचे मोजमाप time ssh myvps 'echo ok' ने करा, कारण हा आकडा tor ने त्या वेळी कोणता circuit तयार केला यावर अवलंबून असतो आणि tor ने दुसरा circuit तयार केल्यावर बदलतो.

Critical path मधील userspace daemon. WireGuard kernel मध्ये चालते आणि network सोबत सुरू होते. Tor ही अशी process आहे जी सुरू होणे, bootstrap पूर्ण करणे आणि कोणत्याही कामापूर्वी guard relay पर्यंत पोहोचणे आवश्यक असते. ती अयशस्वी झाल्यास तुम्ही provider console वर अवलंबून राहता.

Clock accuracy. Onion service descriptors विशिष्ट time periods विरुद्ध प्रकाशित केले जातात. त्यामुळे clock मध्ये मोठी चूक असल्यास कोणत्याही ठिकाणी स्पष्ट संदेश न मिळता address lookup अयशस्वी होते. timedatectl ने System clock synchronized: yes दाखवले पाहिजे.

याच्या बदल्यात तुम्हाला firewall rule योग्य आहे की नाही यावर अवलंबून नसलेली exposure मिळते. Scan करण्यासाठी कोणताही port नसतो आणि मिळवण्यासाठी कोणताही banner नसतो. तसेच address स्वतः public key असतो, त्यामुळे SSH सुरू होण्यापूर्वीच endpoint आपली ओळख सिद्ध करते.

व्यावहारिक उत्तर बहुतेकदा दोन्ही वापरणे हेच असते. दररोजच्या वापरासाठी WireGuard वापरा आणि WireGuard configuration चुकीची असतानाही कार्यरत राहणारा मार्ग म्हणून onion service ठेवा. त्यामुळे public SSH port ऐवजी फक्त एक UDP port उघडा ठेवावा लागतो. यापैकी कोणतीही गोष्ट sshd चे स्वतःचे hardening बदलू शकत नाही. केवळ key-based authentication आणि non-root login अजूनही महत्त्वाचे आहेत, कारण onion service network path चे संरक्षण करते; त्यापलीकडील कोणत्याही गोष्टीचे नाही.

अपयशाच्या स्थिती आणि दिसणाऱ्या त्रुटी

Tor कधीही Bootstrapped 0% पार करत नाही. Outbound traffic अवरोधित आहे किंवा clock मध्ये मोठा फरक आहे. sudo ufw status verbose वापरून outgoing policy तपासा आणि त्यानंतर timedatectl चालवा.

systemctl status tor मध्ये active (exited) असे दिसते. Debian आणि Ubuntu मध्ये हे सामान्य आहे. त्याऐवजी tor@default वाचा.

Descriptor सापडत नाही. Tor SOCKS extended error F0, "Onion Service Descriptor Can Not be Found" परत करतो. Descriptor अद्याप publish झालेला नसू शकतो; reload नंतर यासाठी थोडा वेळ लागतो. किंवा server वरील tor चालू नसू शकतो.

F4, "Onion Service Missing Client Authorization". Client कडे tor वापरू शकेल असा जुळणारा .auth_private नाही. torrc मध्ये ClientOnionAuthDir आहे का, directory चा mode 0700 आहे का, filename चा शेवट .auth_private ने होतो का आणि debian-tor ते वाचू शकतो का, हे तपासा.

F5, "Onion Service Wrong Client Authorization". Private key server वरील .auth file शी जुळत नाही. शेवटी असलेला = किंवा base32 string मधील अनावश्यक newline यामुळे ही समस्या येते.

nc: invalid option -- 'X'. OpenBSD वाला netcat ऐवजी GNU netcat installed आहे. sudo apt install -y netcat-openbsd चालवा.

Could not resolve hostname. ssh ने सामान्य DNS वापरण्याचा प्रयत्न केला. DNS कडे .onion साठी उत्तर नसल्याने ProxyCommand चाललाच नाही. ~/.ssh/config मधील Host pattern तुम्ही टाइप केलेल्या नावाशी जुळत नाही.

Permission denied (publickey). Tunnel यशस्वी झाला आहे आणि tor चे काम पूर्ण झाले आहे. याकडे सामान्य permission denied publickey समस्या म्हणून पाहा आणि tor ला त्यात सहभागी मानू नका.

FAQ

onion service मुळे माझ्या VPS वर खरोखर कोणतेही उघडे पोर्ट राहत नाहीत का?

होय. sshd ला 127.0.0.1 शी bind केल्यानंतर आणि firewall ने inbound traffic drop केल्यानंतर असे होते. Tor relay शी outbound TCP connection तयार करतो आणि तुमचे session त्यामधून परत येते. त्यामुळे server वरील कोणतीही सेवा public address वर connection स्वीकारत नाही. Server वर ss -tlnp चालवून आणि दुसऱ्या ठिकाणाहून port scan करून हे पडताळा. Provider च्या control panel मधील स्वतंत्र network firewall विसरू नका. तो ufw पेक्षा वेगळा असतो आणि तोही बंद असणे आवश्यक आहे.

SSH साठी .onion address स्वतःपुरती पुरेशी सुरक्षा आहे का?

नाही. हा address 56 characters चा असतो आणि directory system मधून त्याचा अंदाज लावता किंवा enumeration करता येत नाही. त्यामुळे तो secret सारखा कार्य करतो. परंतु तो shell history आणि config files मधून उघड होऊ शकतो. v3 client authorisation जोडा. त्यामध्ये service descriptor तुमच्या client key साठी encrypted केला जातो. त्यामुळे केवळ address असलेल्या व्यक्तीला extended error F4 मिळतो आणि ती sshd पर्यंत पोहोचतही नाही.

reboot नंतर tor सुरू होण्यात अपयशी ठरल्यास काय होते?

तुमचा SSH access पूर्णपणे बंद होतो, कारण त्यानंतर आत प्रवेश करण्याचा एकमेव मार्ग onion address असतो. म्हणून port 22 बंद करण्यापूर्वी provider console तपासणे आवश्यक आहे. Boot नंतर Tor ला bootstrap होण्यासाठी वेळही लागतो. त्यामुळे machine ping ला प्रतिसाद देऊ लागल्यानंतर onion address उपलब्ध होण्यास अधिक वेळ लागू शकतो. तो कधीच प्रतिसाद देत नसेल, तर console वर login करा आणि sudo journalctl -u tor@default -b वाचा. तेथे torrc syntax error किंवा /var/lib/tor/ssh वरील permissions समस्या दाखवली जाते.

SSH over Tor हे WireGuard पेक्षा धीमे आहे का?

होय, मोठ्या फरकाने. onion service शी असलेले connection यादृच्छिकपणे निवडलेल्या सुमारे सहा relays मधून जाते. WireGuard मध्ये तुमच्या server पर्यंत थेट एकच encrypted hop असतो. त्यामुळे typing करताना विलंब जाणवतो आणि transfers धीमे होतात. सामान्यतः दैनंदिन कामासाठी WireGuard वापरला जातो आणि चुकीच्या VPN config नंतरही उपलब्ध राहणारा emergency route म्हणून onion service ठेवली जाते.