Tweet
I created a cluster for the first time last night. The setup seems good, the Master and Slave are communicating just fine. However, when I set the Slave as my only DNS and go to google.com it gets blocked, because Unclassified. When I do the same with the Master as my only DNS, google.com is allowed with category Search Engine. I have a feeling that it has something to do with the Cloudlist license not being applied to the Slave. Do I need to manually apply the license to the Slave, or does it transfer over automatically? Thanks for your help.
-
-
If you start master node first and then slave node, it will share the license. But to be 100% sure, copy the license file into /nxfilter/conf of your slave node as well. -
That's what I did, but the license indeed did not copy over, so I stopped the Slave (received email about Slave Node down), then copied over the license, then restarted the Slave (no more emails after). Unfortunately, still the same issue, google.com still doesn't work. I am going to switch the Slave to Stand Alone, then make sure that Cloudlist is selected and activated, then move it back to slave node again, see if that will make a difference.Comment
-
My method did make a difference in that the Master now shows that google.com coming from the Slave is not blocked anymore, however, it's still a no-go on the computer itself. I still cannot reach google.com. For the time being I will just set the Slave up as a Stand-Alone and I will copy over the database from the "Master" so now and then, until you can help me figure out why it is not working. The "Slave" will only be used as a secondary DNS for if the primary goes out, so I don't think this will violate the Cloudlist license.Comment
-
When you do 'nslookup google.com' to your slave node what do you get? Your block redirection IP? Then it may not be able to reach out its Cloudlist server. Do you have any firewall rule for your slave node?Comment
-
The first screen shot shows the command window, the second screen shot shows the request on the Master. Both running on Linux with default (untouched) firewall settings, whatever that is on Linux.
Comment
-
It means that it doesn't resolve. Your client sent a DNS query and your slave node (10.104.1.34) received the query and it processed it and logged it but your client couldn't get any response. You need to find out where's the problem.
You can try to do 'nslookup google.com' from your slave node system. If there's no problem on the same system, there's something between 10.104.1.34 and 10.100.10.43. If you get the same problem then your slave node might have some problem with DNS resolving.Comment
-
I just turned it into a Stand-alone server and now it resolves just fine, so that indicates that there is no problem in between 10.104.1.34 and 10.100.10.43 or 10.100.10.199 (199 is my test computer having only the Slave set up as DNS), so the problem is only when it is in actual Slave Mode.Comment
-
That's weird. I have a cluster using Cloudlist and testing its slave node with nslookup. Works fine.
If it doesn't work when it's in slave mode then it might be hanging with its master connection. Don't know what it is as we don't have such a thing. Try to turn DEBUG on your slave node and then do the test again.
To turn debugging on, https://tutorial.nxfilter.org/i-faq.php#enable-debugComment
-
I've followed your instructions, tried to resolve, but still no luck. You probably need the log file now. Where can I find that and where do you want me to send it to?Comment
-
Never mind, I figured it out by looking at tail -f /nxfilter/log/nxfilter.log feed on screen. It was not able to connect to the upstream server, because I didn't have the IP address of the Slave Node registered in the upstream. I completely forgot about that part. My apologies for wasting your time.Comment
-
Good to hear that and no problem.Comment
Comment