There is not a simple solution because you are trying to change or work around the nature of the underlying technology. The short short answer is that there is no absolute solution. Even TOR which was designed to do this as much as possible is far from perfect (essentially best case is that TOR provides a 50/50 chance that your privacy is maintained). None of this solves the basic problems with our operating systems and browsers (which have now become fully fledged operating systems with Linux, MacOS, and Windows increasing becoming just the driver level).
Again it is really useful to step back and think about what you want to achieve. Who are you protecting your privacy from? This question will drive most of the technology decisions. A VPN merely moves the goal posts, since anything your ISP can see the VPN provider can now see. All you have done is change your "entry" point into the public network. This can have some advantage in that your exit point can be in a different legal jurisdiction, but never assume that you are protected. Large government organizations do not respect these legal borders, so VPNs do protect you from the likes of the NSA, GCHQ, or Canada's own CSE. Your browser is still connecting to the same endpoints, the web sites still use various tracking methods to uniquely identify your connection, and none of this is solved by a VPN. I use VPNs to obscure some traffic from my ISP and to protect traffic when I connect to public wifi access points. I also use VPNs to gain access to on-line media content such as that hosted by the BBC, Netflix or Comedy Central. There are lots of valid reasons for using a VPN, overarching privacy is just not one of them. As for that basic script, you could chop out some lines in the middle, as all it does is allow machines are your LAN to connect to your computer. That script also assumes that your interface is called eth0, on my NUC at home the LAN interface is em0, on this laptop my wifi interface is wlp3s0, and on my old laptop the wifi interface is wlan0. If you type "ip route" from the command line, the line that starts with "default" should tell you the name of the relevant interface. You would also want to allow connections to the DNS servers in use. There are lots of public DNS servers that you could use (Google, OpenDNS, etc.) or you could run your own. The problem is that the DNS queries themselves are in the clear, so anyone actively surveilling you would be able to get that data, regardless of what solution you went with. tldr; This is a deep dark rabbit hole. There are so many different technologies that are a part of the modern Internet, and almost none of them were designed with privacy or even security in mind. To make matters worse there is extreme resistance to change (we have not yet adopted IPv6 in 20 years, and http got it's first revision in more than 15 years recently). Even if we were to design a proper system from scratch, which we could probably do, it would take decades to implement. So to circle around again, always keep in mind what is the data are you trying to protect, and who are you protecting it from? Hth, On Thu, Mar 12, 2015 at 11:36 AM, Joe S <joes...@shaw.ca> wrote: > I have been looking into VPNs the last few weeks. I want to have some > anonymity/privacy so I thought of using a VPN service. From what I have > read in a few articles there can be a problem with 'dns leaks' if the > computer tried to get it's info from the ISP or if the VPN fails the ip > address can be exposed and that VPN services weren't always reliable to > protect from this and thought this script would work if I could fit it > for my situation. I only have one computer so don't know if I need the > IP he used; if I could delete the lines for that or edit the lines. This > is the link to the post I found it from: > http://forums.debian.net/viewtopic.php?f=10&t=108381 > Would like to hear of other solutions. I was hoping to find a simple > solution for this. > > On Wed, 11 Mar 2015 01:27:08 -0600 > Gustin Johnson <gus...@meganerd.ca> wrote: > > > Are you trying to host a VPN server or connect to one? It would > > help to step back and explain the problem and then explain what you > > understand the solution to be. Some context would be really helpful > > (and potentially help you avoid solutions that don't really fix your > > problem... this is pretty much the story of my career). > > > > From the script that you posted it appears that you are setting some > > iptables (aka "firewall") rules allowing all traffic on the eth0 > > interface of some host from all computers in the network range of > > 192.168.1.1-255. It appears that you are also attempting to allow > > this machine to make DHCP requests and to connect to some vpn servers > > pulled from openvpn config files. This would indicate that you want > > to connect your machine to an openvpn server to protect your traffic > > from snoopers on the first couple of hops, but you don't need > > iptables to do that. > > > > Basically it looks like an overly complicated (but not a complete or > > thourough) client configuration. You don't need iptables to connect > > to an openvpn server. This is where the context would be handy. > > > > *** Begin what is probably insanely boring background information for > > most sane people. *** > > > > 192.168.XX.XX addresses are one of the blocks set aside for "private" > > use. That is they were never intended to be used on the Internet, > > just small private, disconnected networks. When we started running > > out of IP addresses 20 years ago, some people came up with the idea > > of Network Address Translation (NAT) where you could have a router > > hide these private networks behind a single publicly routable IP (a > > "real" IP address out on the Internet). > > > > 192.168.0.0/24 (basically 192.168.0.1-255) is commonly used in off the > > shelf routers (Dlink, Linksys, TP-Link, Asus etc.) and in a lot of > > examples in do DIY solutions. > > > > 10.XXX.XXX.XXX and 172.16.XXX.XXX are some other "private" IP blocks. > > > > What this all means is that your computers on your LAN that are > > behind your router probably have an IP address like this. The thing > > is no one on the Internet can initiate a connection to them directly, > > they have to connect to your router's "external" (Shaw provided) IP > > address, and then maybe the router will forward that packet to an > > internal host (this is usually known as port forwarding). This is > > not usually a problem when you connect because your machine will > > connect to the router, which will then "remember" that your computer > > sent the request, and then forwards all the replies to your computer. > > > > *** End boring stuff. If you want to really get to know networking > > and Linux, lartc.org is *THE* place to go first. *** > > > > > > On Tue, Mar 10, 2015 at 11:07 PM, Joe S <joes...@shaw.ca> wrote: > > > > > I found this script and am trying to get it to work for my > > > computer. It is to restrict connections to the VPN. The thing I > > > don't understand is what IP address to use. I have been looking > > > on the NET, but am not familiar with networking. In this script > > > the person uses 192.168.1.0/24 > > > I think this is for a network. I am connected to shaw through a > > > cable modem, so I need to know what IP would be used in my > > > case. > > > > > > Thanks > > > > > > > > > #!/bin/sh > > > > > > /sbin/iptables -P INPUT DROP > > > > > > /sbin/iptables -A INPUT -i lo -j ACCEPT > > > > > > /sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j > > > ACCEPT > > > > > > /sbin/iptables -A INPUT -i eth0 -s 192.168.1.0/24 -j ACCEPT > > > > > > /sbin/iptables -A OUTPUT -o eth0 -d 192.168.1.0/24 -m state --state > > > RELATED,ESTABLISHED -j ACCEPT > > > > > > /sbin/iptables -A OUTPUT -p udp --sport 68 -j ACCEPT > > > > > > /bin/grep -h '^remote ' /etc/openvpn/*.ovpn | /usr/bin/cut -d ' ' > > > -f 2 | /usr/bin/sort -du | /usr/bin/xargs -I @ /sbin/iptables -A > > > OUTPUT -d @ -j ACCEPT > > > > > > /sbin/iptables -A OUTPUT -o eth0 -j REJECT > > > > > > _______________________________________________ > > > clug-talk mailing list > > > clug-talk@clug.ca > > > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > > > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > > > **Please remove these lines when replying > > > > > > _______________________________________________ > clug-talk mailing list > clug-talk@clug.ca > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > **Please remove these lines when replying >
_______________________________________________ clug-talk mailing list clug-talk@clug.ca http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
