I successfully installed my SQUID-PRIVOXY-TOR chain to let some PC navigate over the TOR sites.
My SQUID version is 3.5.20;
my Privoxy version is 3.0.33;
my TOR version is 0.3.5.18.
I face with both V2 and V3 onion addresses, referring to V2 the onion addresses 16-char long and to V3 the onion addresses 56-char long; all ports are open, the services are up and running and configurations seem to be good.
What sounds strange to me is that I successfully navigate to a 56-char long address, but I can't with 16-char long address.
In privoxy log I read:
Tor[8718]: Service address [scrubbed] has an invalid length. Expected 56 but got 16.
Tor[8718]: Invalid onion hostname [scrubbed]; rejecting
Can TOR 0.3.5.18 handle old 16-char long onion websites?
Or, have I rollback to some older TOR version to handle them?
With my new configuration are 16-char long onion address useless or can I continue to use them in some way?
thank you all for any advice,
Pietro
V2 addresses are useless. Their EOL was October 15th, 2021.
https://blog.torproject.org/v2-deprecation-timeline/
Pietro
Related
Could deploy Bosh and small footprint tanzu application service(tas) in Azure, without using the domains.All Vms are running.Can i access the ccapi and apps manager with the IP address instead of the api.SYSTEMDOMAIN?
The short answer is no. You really, really want to have DNS set up properly.
Here's the long answer that is more nuanced.
All requests to your foundation go through the Gorouter. Gorouter will take the incoming request, look at the Host header and use that to determine where to send the request. This happens the same for system services like CAPI and UAA as it does for apps you deploy to the foundation.
DNS is a requirement because of the Host header. A browser trying to access CAPI or an application on your foundation is going to set the Host header based on the DNS entry you type into your browser's address bar. The cf CLI is going to do the same thing.
There are some ways to work around this:
If you are strictly using a client like curl where you can set the Host header to arbitrary values. In that way, you could set the host header to api.system_domain and at the same time connect to the IP address of your foundation. That's not a very elegant way to use CF though.
You can manually set entries in your /etc/hosts` (or similar on Windows). This is basically a way to override DNS resolution and supply your own custom IP.
You would need to do this for uaa.system_domain, login.system_domain, api.system_domain and any host names you want to use for apps deployed to your foundation, like my-super-cool-app.apps_domain. These should all point to the IP of the load balancer that's in front of your pool of Gorouters.
If you add enough entries into /etc/hosts you can make the cf CLI work. I have done this on occasion to bypass the load balancer layer for troubleshooting purposes.
Where this won't work is on systems where you can't edit /etc/hosts, like customers or external users of software running on your foundation or if you're trying to deploy apps on your foundation that talk to each other using routes on CF (because you can't edit /etc/hosts in the container). Like if you have app-a.apps_domain and app-b.apps_domain and app-a needs to talk to app-b. That won't work because you have no DNS resolution for apps_domain.
You can probably make app-to-app communication work if you are able to use container-to-container networking and the apps.internal domain though. The resolution for that domain is provided by Bosh DNS. You have to be aware of this difference though when deploying your apps and map routes on the apps.internal domain, as well as setting network policy to allow traffic to flow between the two.
Anyway, there might be other hiccups. This is just off the top of my head. You can see it's a lot better if you can set up DNS.
The most easy way to achieve a portable solution is a service like xip.io that will work out of the box. I have setup and run a lot of PoCs that way, when wildcard DNS was something that enterprise IT was still oblivious about.
It works like this (excerpt from their site):
What is xip.io?
xip.io is a magic domain name that provides wildcard DNS
for any IP address. Say your LAN IP address is 10.0.0.1.
Using xip.io,
10.0.0.1.xip.io resolves to 10.0.0.1
www.10.0.0.1.xip.io resolves to 10.0.0.1
mysite.10.0.0.1.xip.io resolves to 10.0.0.1
foo.bar.10.0.0.1.xip.io resolves to 10.0.0.1
...and so on. You can use these domains to access virtual
hosts on your development web server from devices on your
local network, like iPads, iPhones, and other computers.
No configuration required!
I am a user of OpenDNS, and I am noticing network traffic to weird subdomains on my local area network. Suppose the "Local Domain Name" setting on my router is named "mynetwork". I am seeing many requests to domains like:
lb._dns-sd._udp.mynetwork
db._dns-sd._udp.mynetwork
b._dns-sd._udp.mynetwork
tvovhvumfcuvo.mynetwork
pqwakwyids.mynetwork
vbqulcywazgwao.mynetwork
wjyuspdzzbac.mynetwork
etc.
If this is not normal traffic how should I discern where my problem lies? Should I install something like "Little Snitch" on my Macs for example?
You may want to check out this answer from menandmice, where they say:
These are queries generated by 'Multicast/Unicast DNS Service Discovery or
Zeroconf', which is a service of Apple 'Bonjour/Rendevous' or Unix Services like
'Avahi'. DNS Queries coming from Port 5353 are DNS queries from a Zeroconf service.
The DNS Service Discovery enabled clients are looking for pointers to services running in their network block 192.0.2.0/24.
This is harmless. If there is not PTR record for the requested ownernames, it
only means that unicast Zeroconf is not configured.
"unicast Zeroconf is not configured" might not be your exact problem, but overall it's nothing to worry about.
Note: this problem is independent of wire/wireless, iPad (with Google DNS)/Linux/Windows
I can't access several sites including stackoverlow (cdn.sstatic.net), aws.amazon.com (d36cz9buwru1tt.cloudfront.net), heroku, github etc for 3 days from Turkey with ISP Superonline.
When I try to enter aws.amazon.com, browser downloads html and some images properly but can't download some of them, those hosted on d36cz9buwru1tt.cloudfront.net or subdomains like that.
Chrome says several images from this subdomain are pending. So the web page loading never finishes.
I can't access http://d36cz9buwru1tt.cloudfront.net, it keeps loading for a while (30 sec to minutes). But when I use proxy over Amsterdam, it loads immediately.
Without proxy, I can get its IP with ping:
64 bytes from server-54-240-162-83.fra6.r.cloudfront.net (54.240.162.83): icmp_req=1 ttl=53 time=58.2 ms
While writing these, the previous URL became available after several hours and now github.com can't be accessed due to css files on its CDN: https://github.global.ssl.fastly.net/assets/github2-f227c0e7c55002ba0645fc8d3761d00bce36e248.css
$ wget https://github.global.ssl.fastly.net/assets/github2-f227c0e7c55002ba0645fc8d3761d00bce36e248.css
--2013-11-19 21:39:32-- https://github.global.ssl.fastly.net/assets/github2-f227c0e7c55002ba0645fc8d3761d00bce36e248.css
Resolving github.global.ssl.fastly.net (github.global.ssl.fastly.net)... 185.31.17.184, 185.31.17.185
Connecting to github.global.ssl.fastly.net (github.global.ssl.fastly.net)|185.31.17.184|:443... connected.
...
...
waits but no response.
What could be the cause of this problem? My ISP did not help.
UPDATE: Changing my IP has solved the problem. Seems like someone using that IP before me got banned by Cloudfront.
I also had the exact same problem, Changing the DNS solved the issue. For me Coursera wasn't opening, neither 9GAG.
Changed my default DNS server provided by my ISP to the one given by google i.e.
8.8.8.8 and 8.8.4.4
I hope this solves your issue as well.
It seems there is a lot of problems with some ISPs and DNS resolution on CloudFront. See this https://forums.aws.amazon.com/thread.jspa?messageID=263168
Have you tried to change your DNS?
I also have the exactly same problem; same situation as you.
I think we really experience exactly the same. (but for me happen just today)
I first noticed problem on cloudfront then fastly then I can connect to cloudfront but fastly.
To answer your question I have a possible speculation about the root of the problem.
However, if this speculation is true the issue can't be solved on our end.
I think it's because of LSN (or NAT444, CGN) that installed in ISP network.
(ISP don't want customers to notice this change.)
To check if this speculation is plausible please check your modem/router
if the IP address received from ISP is in this block 100.64.0.0/10
then that should explain the phenomenon.
My ISP recently deploy LSN short before this problem arise.
I think IP address pool in LSN is too small (poorly deploy by ISP) so too many users share the same IP address.
this cause CDN networks to think they got DOS attack from particular IP address.
then CDN networks will temporary block (or null route) the LSN IP address.
some note: I'm sure this is not about the DNS because fastly deploy some trick called "round robin DNS" to use with "client retry" and I tried connect more than one IP address from fastly and also check that the values (All A records received) are correct.
To workaround the issue you can setup SOCKS proxy on a VPS and write PAC script to redirect some traffic thru the proxy.
I'm writing a small DNS proxy. It listens for incoming UDP messages on a port and resolves them using a specified DNS (e.g. google's DNS 8.8.8.8) and sends the response back to the client.
I would like to be able to detect the default DNS a machines uses. Every OS has an option to obtain the DNS server address automatically. I was wondering how this is done. Is there a protocol on top of UDP or TCP, or something else entirely?
I'm using C#, but the language isn't important.
Finding which DNS the current computer uses as default is highly dependent on both which OS you use and which language you use. If you use Java or .NET, or another platform independent language you might not need to worry about the OS bit though.
Client computers usually "auto-discover" which DNS to use in the DHCP response from the DHCP server. That is when they receive their IP address they also get which DNS server to use. They might also get addresses to WINS servers and a multitude of custom options.
You can find the DNS server by typing ipconfig/all in coand prompt. This will gove you the address of your DNS server.
Our user interface is communicating with another application on a different machine, often connecting using domain names.
On our network, when IPv6 is installed, DNS name resolution works great, all machines can be pinged and contacted fine.
When IPv6 is uninstalled, pinging the same DNS names returns an IP address on some distant subnet (24.28.193.9; local subnet is 192.168.1.1); our application is then unable to communicate. When IPv6 is reinstalled, the DNS resolution corrects itself.
Even without IPv6 when ping is not working, I can still browse other machines using Windows Explorer by entering \\\\MACHINE_NAME\\. I'm not sure why the name resolution seems to work here. We are working in the Windows XP SP2 environment.
The IPs of the machines can be pinged successfully. It is only the DNS names that do not resolve properly.
I looked for the address of our DNS server. All of our computers are pointing at the network gateway, which is a wireless router. The router has the same DNS server address listed when IPv6 is installed as it does when it isn't installed.
The strangest thing is that I just discovered that it does not matter what DNS name I ping. All pings to DNS names return the same address: "24.28.193.9".
I tried flushing the DNS Resolver Cache and registering DNS on the target machine and the source machine. All to no avail. The only DNS name that I can ping is the name of the current machine.
Any thoughts as to why our software can't communicate without IPv6 installed?
UPDATE:
OK, I've done a little more research now.
I looked for the address of our DNS server. All of our computers are pointing at the network gateway, which is a wireless router. The router has the same DNS server address listed when IPv6 is installed as it does when it isn't installed.
The strangest thing is that I just discovered that it does not matter what DNS name I ping. All pings to DNS names return the same address: "24.28.193.9".
I tried flushing the DNS Resolver Cache and registering DNS on the target machine and the source machine. All to no avail. The only DNS name that I can ping is the name of the current machine.
Any other suggestions? Thanks so much for your help.
You've got multiple things going on here
DNS Name resolution
Windows Name resolution
IP-IP ICMP communication
You've written your question as if there's a problem with #3, but everything you describe points to the problem actually being with #1. If you take resolution out of the question, can you ping the correct IPs with our without IPv6 installed?
It sounds like maybe you have an IPv6 name server installed that has correct information and the IPv4 name server is incorrect? Are you receiving name servers via DHCP or hard coding? What are the IPs of the name servers you are using when IPv6 is installed and when it isn't?
I know this is a late answer, but in case someone else has the same problem, the key is the IP address, "24.28.193.9". A quick Google search reveals it seems to be related to your ISP completely breaking the DNS protocol by returning a fixed IP address for all non-existent domain names (the correct answer would be NXDOMAIN). Your network gateway is most probably just forwarding your queries to your ISP's name servers.
Your systems are relying on the correct operation of the DNS protocol. They are expecting a NXDOMAIN answer before querying the name via other methods (most probably NetBIOS name resolution). Since the DNS server is completely broken and returning an incorrect answer, the correct address is never looked up.
The reason installing or uninstalling IPv6 changes the situation is most probably because something related to it is changing the name resolution order (to look up using other methods before trying DNS). So, a workaround would be to change the name resolution order yourself.
The real fix would be to either change to a better ISP (one which does not break established protocols) or run your own DNS server (which is what I started doing on all systems I administer ever since VeriSign pulled a similar stunt; theirs was even worse in that changing ISPs made no difference at all).
References:
Warning: Road Runner DNS says nonexistent domains exist