Implemented '--tor inside' option to run inside of the Tor-connected virtual machine#484
Implemented '--tor inside' option to run inside of the Tor-connected virtual machine#484yurivict wants to merge 10 commits intoHelloZeroNet:masterfrom
Conversation
Current coverage is 47.95%@@ master #484 diff @@
==========================================
Files 55 56 +1
Lines 6579 6725 +146
Methods 0 0
Messages 0 0
Branches 1379 1401 +22
==========================================
+ Hits 3188 3225 +37
- Misses 2993 3098 +105
- Partials 398 402 +4
|
|
The new --tor_hidden_services option expects the file containing the hidden services in this format: Onions can be generated using Shallot (https://github.com/katmagic/Shallot): |
yurivict
changed the title
|
Please hold this. I need to troubleshoot some issues first with my setup. I will update this PR's patch when done and when I will see that it works 100%. |
|
OK,, I think renaming to --tor manual would be more straightforward, because it could be also useful without VM |
|
Ok |
|
Actually, this mode can't work outside of the VM, because it needs DNS resolution hooked up to Tor and IP routed through Tor, which I never saw to be done outside of the VM. The possible environments are:
So I am not very excited by the name "manual" here because it doesn't reflect what it is very well. Maybe we should name it "embedded"? "Embedded" reflects the meaning better, because ZN is "embedded" into the Tor-VM environment ? |
…site, onion limit enforced.
…connections for the unknown sites, improved debug messages.
|
@HelloZeroNet Hi, I finished this feature. Tested it in VM, ZN works without any problems. So do you agree to rename it into "embedded": |
|
I'd also like this implemented. Good work! |
|
Thanks! I use it in a VM ever since I implemented it 1.5 months ago without a problem. |
|
@HelloZeroNet Why is this PR not merged? |
|
@yurivict testing inside QubesOS whonix-14-ws qube, following zeronet unworking guide which permits access but not hosting sites (@adrelanos !!!) Any insight? |
|
Actually, I double read and understood that fileserver and tor-inside were mutually exclusive. |
|
How many onions did you supply? |
|
@yurivict : only one. Deleting all ./data directory and starting blank doesn't recreate the error. A clean clone of your repo doesn't recreate the error. But once sites are added, the error reappears. Complaining with exponential required onion sites, where only one is necessary: the onion site configured into sys-whonix, which routes correctly the traffic to the zeronet qube, which is tested by port check and reachable from the outside world. |
|
It has this condition I will review and rebase the code, and will try to see if a limited set should suffice. But this seems to be how ZeroNet itself operates - it creates a lot of onions. In |
|
The |
In my comprehension, the correlation from tor hidden service to me as the publisher would happen only if the number of peers is 2 for a new ZeroNet service, and on even that, it doesn't mean the that peer is downloading from the publisher itself, nor that all single peers or publisher are online all the time. Pointed consideration is valid only when a site update is published to the first peer, after which it is difficult to trace back to the original hoster since that peer may be taken to update the zite copy of other peers in place of the publisher itself. I understand the consideration though, but current error should still be a warning at best. A single onion site should be sufficient for a single ZeroNet instance. I'm not "hosting" 99+ sites myself in the current example, but redistributing sites I visited (I swear I do not have that numsites+1 under /data, still). As for the previous point, this is still a bug and not a feature of current tor-inside addition. The user should not have to constantly maitain onion hostnames list to be both fillled to sys-whonix and ZeroNet as a consequence of visiting new zites, which results in him hosting those new sites himself for others. At the end of it all, the same attacks to deobfuscate all those 99+ generated .onion site are the same as for identifying tor users/hidden onion services : timed attacks, DoS and most importantly, targeting and cutting down an hypothesized hidden onion linked internet connection and validate service unavailability, which would all point out to my qube and zeronet onion service being down whatever number of onion hidden sites generated, while the other peers hosting my zite would still distribute the latest version they have got from me or indirectly from me and prviding to others, which is a strong resilience feature of ZeroNet and other similar redundant/decentralized services. Have I missed something? |
|
@yurivict : ping? |
| # check if there are enough onions available | ||
| if sys.modules.get("main") and sys.modules["main"].file_server: | ||
| tor_manager = sys.modules["main"].file_server.tor_manager | ||
| if tor_manager and tor_manager.numOnions() < serving+1: |
There was a problem hiding this comment.
This is unpractical. serving here refers to the number of sites visited, not hosted. I would remove that condition completely.
|
@tlaurion I will be out of town next week, will correct it after next Sunday. |
|
@yurivict any update? Sent from my Galaxy S3 using FastHub-Libre |
|
@yurivict? Any problems? |
|
@yurivict : Sorry to insist, but this feature is really important. |
|
Any onion-grater filtered messages in journal?
sys-whonix:
sudo journalctl | grep filtered
|
|
@adrelanos: Accessing content works. Publishing doesn't. Following official guide on whonix14 for QubesOS, here is the result after having started zeronet. Setup: two whonix-ws workstations. Connectivity: Publisher: It's sys-whonix: Client: It's sys-whonix Config of both sys-whonix: |
|
Command filtered messages will interfere very likely with publishing. This could be it. does not match the profile anymore I don't follow ZeroNet development. Any changes to Tor implementation or underlying libs? Attempted a quick untested fix: You could try the updated profile from git: Perhaps also either: or is required. Also, perhaps also either: or Out commented code for that is already in the profile. Don't forget after profile changes. To prevent another source of confusion from happening for any reader, the path has changed Whonix 14 vs Whonix 15 and above: Whonix 14: Whonix 15 and above: |
|
@adrelanos : commented in Whonix/onion-grater@e994509 |
|
|
Another attempt to fix: This time palatially tested: No more filtered messages. Same location as before. Let me know how that goes. |
|
Compared to similar applications using onion-grater...
https://www.whonix.org/wiki/ZeroNet lacks the Just now added. https://www.whonix.org/w/index.php?title=ZeroNet&type=revision&diff=47067&oldid=46740 Consider it optional for now - if it works without - then leave it out. But if publishing doesn't work - try if that helps. |
|
@adrelanos : Works! The firewall part is required on both client and publisher to be able to interact with sites. (In my test scenario of only 2 peers, a client and the original site publisher, only reachable through tor.) To test this, I simply added a post on the publisher with the firewall conf in, and not present on the client side, and the client side failed to update (liking posts never reached original publisher). When both have firewall conf in, the changes are propagated fluently. |
|
Great, thanks! I am a bit but not too much surprised the client needs to do this too. I would guess ZeroNet utilized Tor onion services in both, publisher and client mode. Instructions https://www.whonix.org/wiki/ZeroNet were updated too just now. These instructions don't mention publisher vs client mode. They're the same for everyone. So should work for anyone following these instructions. |
6 participants
This implements my suggestion: #474
I tested ZN inside the Tor-connected VM and it works fine.