Quote:
|
I think I'm giving up on OpenVPN after reading many different guides on getting started with it. Too many different ideas on how to secure it, too complex, too many different places to make mistakes and have stumbling blocks. For on-the-road access, I'm more comfortable with the simple and limited ssh on custom port. Even if someone gets the key file, the passphrase still protects it, and it's only for a single non-root user.
For internal use within my LAN, it seems OpenSwan may be easier to set up. Fits on one page: https://wiki.debian.org/HowTo/openswan (Obviously, I'll use "systemctl restart ipsec" rather than the init.d script.) Since I'll be using this strictly for computer-to-computer access within a shared LAN, I'll need to set up dummy interfaces rather than "real" subnets, but this seems simple enough. |
Quote:
|
Quote:
Even though (Open)VPN documentation is not the best, in my blog, right here, I have sincerely attempted to share the :banghead: product of :banghead: my experiences :banghead:, and I am happy to write more installments. I found that there are basically two obstacles to the adoption of VPN, among users who are accustomed to SSH:
"Real-world" encryption technologies are all about "Alice and Bob, and Eve." (And they never(!) assume that "Eve" can actually "successfully pretend to be Alice, such that Bob cannot tell the difference," merely(!) by "Saying the Magic Word!™") :eek: Therefore, they do require a certain amount of patience. Until you get "the entire(!) incantation" just right, the door will not open. And, quite by design, it will strive to give you "not one single miserable hint" what you (presumed to be "Eve!") did wrong. However, if you persevere, just one time, you will be rewarded with ... silence. With security logs that are ... empty. |
P.S.: I will be more than happy to write new articles in my blog, here. :)
|
Like I noted before, I looked at your four blog articles, and none of them describe how to set this up.
I'm actually a bit puzzled that you don't already have some sort of documentation of what to do. I have set up various things on my main server, and I have instructions for myself on how to do it all over again. These instructions aren't entirely readable for others, but I include enough detail for myself to replicate what I've done. I've done so several times, because I like to have a drop-in replacement server and I also like to occasionally do a fresh reinstall (about once every Debian Stable release). I mean, look at my blog. All 8 of my blog posts are detailed instructions on how to do something. Do you think that's only for the benefit of others? Nope, I'm sure the person who refers to them the most is myself. So, not only do I say why you'd want to do X, I also describe how to actually do X. It helps others, sure, but it also helps myself. My point is - if I had to build a replacement server and install/set up from scratch, I could and it would be done in one night's work thanks to the instructions I maintain for myself. So why don't you have your own instructions, even if only for your own use? Are you confident that you could replicate your VPN server quickly after a fresh linux install? If not, why not? I personally wouldn't be comfortable with anything I couldn't set up over again in a straightforward way. When I set up a new server, I don't expect to bang my head against a wall. I expect to follow my notes and for it to work. Note that you don't need to make a blog post that's more "user friendly" than an info dump. Sometimes, your notes consist of little more than fragments of configuration files and copy/paste commands to enter. It may not be the easiest thing for others to comprehend, but you can just post an info dump and then maybe modify it later with explanations. A lot of times, just seeing raw config file fragments can be more helpful than a wordy description of what to do in the abstract. (My own blog posts combine wordy descriptions with config files/script fragments.) As for security logs - as others have already noted, this just isn't a problem with ssh on a custom port. Custom ports for ssh just don't get hit often, and even if they did it doesn't matter with password authentication turned off. |
A VPN server is much harder to set up than an SSH server. IMHO, there's no comparison between the two in that regard. You will have to don your learning hat to get the most functionality/security out of VPN if you don't already know how to configure it. Same goes for SSH, but the learning hat is much smaller.
Saying "always use UDP for VPN" is entirely too simplistic. I agree that most of the time, for most users, UDP is the way to go. However there are times when TCP will offer more functionality (breaking through restrictive firewalls), or (paradoxically) better performance (when faced with large scale packet loss or rearrangement of packet order). Next up, you have to decide it you want a TUN or a TAP VPN setup. TUN is also called "a routed VPN" and TAP is called "a bridged VPN". Bridging is easier to set up and comprehend, but routed gives you more fine-tuned control. e.g., You can easily firewall stuff with a routed VPN - not so easy in a bridged one (you can't use iptables for something that is bridged, you have to go to a lower level). So your choice between TAP/TUN will depend on the level of access you want to grant and the amount of trust you have in your VPN users. You can assign VPN users specific IP addresses based on their cert. So when "Fred" comes in, you know it is him for sure, you give him a specific IP address that does not vary, and thus you can control what he can access via iptables rules (on a routed VPN). "Bob" then comes in, has a totally different IP address assigned to him, and you can give him completely different access to things than you gave to "Fred". VPN is more powerful and flexible than SSH. But with that power and flexibility comes quite a bit of added complexity. And the more you want to up the security, the more complex it gets as well. login/password is the least secure, but the easiest to set up. Next, in the SSH world, comes pubkey authentication. Much better than login/password. But not as good as certificates. Certificate authentication is the standard in VPN (although you can set authentication in other ways). I consider pubkey the standard for SSH in my installations, but many would argue that login/password is the standard in their installations. You can use certificates in SSH. I am not up-to-date in OpenSSL vs. certs. It used to be that OpenSSL (opensource, free) didn't support them, but maybe they do now. I remember having to use Tectia SSH (commercial, paid) to enable client cert authentication years ago for a specific installation at work. SSH is much easier to test than VPN. Assuming you are sitting at home and all your devices are on the same LAN, you can't bring up a VPN for testing (well you can, but it won't work reliably, probably not at all). This is because packet routings get very confused deciding to send packets directly over the LAN, or over the LAN via the VPN. SSH does not have this constraint, and you can easily test it with all devices on the same LAN. Conclusion: There is no one answer to VPN vs. SSH. No one answer to UDP vs. TCP. No one answer to TUN vs. TAP. No one answer to login/password vs. pubkey vs. certificate authentication. Every situation has a different balance of ease vs. complexity and ease vs. security. Put on your learning hat and do some research before making a decision. FWIW - at home, I run VPN on my router. Two instances. One is TUN/UDP, the other is TAP/TCP. Remotely I can connect either way, depending on the situation. But since I only implicitly trust myself, other users of my VPN (limited family members) are all TUN/UDP only. While they are trustworthy, I'm not so sure about the other environments that connect in, thus their actual devices could be compromised. My family VPN users are very tightly firewalled. By default they can't connect to anything, zero network activity allowed, unless I explicitly grant a specific access to each of them, on an individual basis. My router runs OpenVPN. There is a GUI for administering it. But I do not use that. I use good old manual config files that I set up from scratch. I do not trust the GUI configuration to do what I want to do. You never really know what those little GUI checkboxs actually do down in the bowels of the OpenVPN configuration. Some are obvious, others are not. Also, I run SSH on my home router. Pubkey only. Very tightly configured. I am the only user allowed in. While SSH/pubkey is weaker than VPN/certificate, the way I have it configured it is strong enough for my personal needs, which is what matters. Also, iptables on my router. Again, manually configured - not with the GUI checkboxes provided in the user interface. |
Quote:
jlinkels |
Quote:
|
Quote:
"ssh" operates at a level above "the TCP/IP stack," while "VPN" operates within it. |
Quote:
|
Quote:
Quote:
Quote:
|
Quote:
Code:
Protocol 2 |
Quote:
*Less security through obscurity than log management. |
Quote:
Quote:
|
All times are GMT -5. The time now is 01:22 PM. |