Difference between revisions of "Talk:OpenVPN"
(→Using openvpn scripts to set promiscious mode (and ipforwarding): remove accuracy template as the suggestion doesn't fit very well with the configs in the article and is deemed insecure by upstream) |
(→Moving the Creating a Public Key Infrastructure (PKI) section) |
||
Line 66: | Line 66: | ||
==Moving the Creating a Public Key Infrastructure (PKI) section== | ==Moving the Creating a Public Key Infrastructure (PKI) section== | ||
Maybe it would be a good idea to move the creating a PKI section to its own page (easy-rsa) would be a good idea? It would make this article a lot terser and more to the point. Any comments? -- [[User:Jhernberg|Jhernberg]] ([[User talk:Jhernberg|talk]]) 11:45, 24 August 2012 (UTC) | Maybe it would be a good idea to move the creating a PKI section to its own page (easy-rsa) would be a good idea? It would make this article a lot terser and more to the point. Any comments? -- [[User:Jhernberg|Jhernberg]] ([[User talk:Jhernberg|talk]]) 11:45, 24 August 2012 (UTC) | ||
+ | |||
+ | : This has also been done now. | ||
+ | : -- [[User:Jhernberg|Jhernberg]] ([[User talk:Jhernberg|talk]]) 16:05, 25 August 2012 (UTC) | ||
==L2 ethernet bridging== | ==L2 ethernet bridging== |
Revision as of 16:05, 25 August 2012
Contents
- 1 Missing details
- 2 Link to upstream document instead of duplicating
- 3 Verbosity of article
- 4 Instructions on adding tun/tap support to the kernel configuration
- 5 Using openvpn scripts to set promiscious mode (and ipforwarding)
- 6 Moving the Creating a Public Key Infrastructure (PKI) section
- 7 L2 ethernet bridging
- 8 Proposed sections for future expansion of the article
- 8.1 Pushing DHCP options to clients
- 8.2 Configuring client-specific rules and access policies
- 8.3 Routing all client traffic through the server
- 8.4 Running an OpenVPN server on a dynamic IP address
- 8.5 Implementing a load-balancing/failover configuration
- 8.6 Locking down security
- 8.7 Revoking certificates
- 8.8 Configuring iptables for use with OpenVPN
Missing details
There are some things that I think would have been extremely helpful to add in this article, primarily relating to iptables. For example, in Routing_the_LAN_of_a_client_to_the_server it might have been useful to say, "do something like iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 10.4.4.30" rather than "Use the iptables NAT feature to masquerade the IP packets."
I think more handholding would help this article a lot--it certainly would have helped me figure this out much faster. If no one disagrees, I'd like to add several sections on appropriate iptables rules to add. Buhman 17:11, 9 April 2012 (EDT)
- No objections, all constructive contributions are welcome, just remember that an article shouldn't be just a list of instructions: "handholding" is fine as long as it also explains why something needs to be done, so in your example above the existent sentence should be kept and your iptables line should be presented just as an example. -- Kynikos 08:46, 10 April 2012 (EDT)
- To be honest, I think this article, the way it is now, uses way too much handholding. (I liked it more the way it was [1] ). It have things like: "Edit /root/easy-rsa/vars and at a minimum set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters (do not leave any of these parameters blank)", instead of just "Edit /root/easy-rsa/vars according to your preferences"
- Maybe the solution could be the path Beginners' Guide and Installation Guide took; One, super handholding-type guide, and the other as a checklist-type guide... hmm, maybe I'll write such article Chrisl (talk) 18:48, 16 August 2012 (UTC)
- I have some time to work on this again (vacation), hopefully I'll get at least some more stuff done. If someone wants to add iptables instructions please go ahead. There is some preliminary stuff that Kynikos uncovered :) Too much, too little handholding, it's hard too say, and it looks like opinions differ. Maybe let me be verbose and then try to tighten it up and remove unwanted verbosity? jhernberg 21:50, 16 August 2012 (UTC)
In any case, the article still needs a lot more information about the various ways that openvpn can be configured, and any help would be very much appreciated...:) jhernberg 21:55, 16 August 2012 (UTC)
- Well, I have created the checklist-type article, is here: OpenVPN Checklist Guide Right now, it has lots of things of the old openvpn article, but shorter. The idea is that it have links like "click here to see more details" pointing to the section of a full article explaining something, to avoid repetition. I must add that I think this way is more KISS. Chrisl (talk) 04:55, 17 August 2012 (UTC)
Link to upstream document instead of duplicating
This page is already a little long. OpenVPN has lots of good document here. It is better give some entry point and link to the upstream document instead of duplicate info here. After all, it is Arch Wiki, not OpenVPN wiki. -- Fengchao (talk) 03:38, 17 August 2012 (UTC)
Verbosity of article
I thought one mantra of the archwiki was "Don't just give me the 'how' - give me the 'why'", is that no longer so? Seeing that I don't seem to be able to be as terse as you guys want me to be, maybe I'd better leave the article in your hands instead? jhernberg (talk) 14:33, 17 August 2012 (UTC)
- #"Don't just give me the 'how' - give me the 'why'", is that no longer so?
- The answer is absolutely yes.
- #Seeing that I don't seem to be able to be as terse as you guys want me to be maybe I'd better leave the article in your hands instead?
- In the talk page, we talk about the page not the author. And it is a wiki page, it belongs to nobody. Everyone can improve it.
- This page is in very high quality and help the Arch users a lot. Your effort are appreciated and please do not leave. :)
- As the page length, it is only a suggestion. Many long pages on Arch Wiki duplicate text from upstream document. When upstream change something, these text may quickly become out of date. This is why stick to the upstream become a part of Arch philosophy.
- -- Fengchao (talk) 03:32, 18 August 2012 (UTC)
Instructions on adding tun/tap support to the kernel configuration
If no one objeccts I will remove the instructions on how to add tun/tap support to the kernel configuration. After all the default kernel has the module, so it really doesn't belong in this article? -- Jhernberg (talk) 13:25, 23 August 2012 (UTC)
The default kernel is already properly configured, but if you build your own kernel make sure to enable the TUN/TAP module.
Kernel config file
Device Drivers ---> Network device support ---> [*]Network device support <M> Universal TUN/TAP device driver support
To see if your running kernel has this support enabled, run the following and check the output:
[myuser@rpi0 ~]# zgrep CONFIG_TUN /proc/config.gz CONFIG_TUN=m
CONFIG_TUN should be either 'm' or 'y'.
Using openvpn scripts to set promiscious mode (and ipforwarding)
To me it appears a bad idea to use scripts to do this, as a server might conceivably have it enabled for other reasons than openvpn. Personally I'd be inclined in having the administrator hard code such changes to the system. If no one objects, i'll remove the accuracy template. Who knows maybe it could be added to a tips section or as its own entry. -- Jhernberg (talk) 17:10, 23 August 2012 (UTC)
- Have removed the accuracy template from the main page and put it here. Additional reasons to the above is that upstream has by default disabled scripts for security reasons, also the configs in this article drop root privs again for security reasons.
Moving the Creating a Public Key Infrastructure (PKI) section
Maybe it would be a good idea to move the creating a PKI section to its own page (easy-rsa) would be a good idea? It would make this article a lot terser and more to the point. Any comments? -- Jhernberg (talk) 11:45, 24 August 2012 (UTC)
L2 ethernet bridging
I was going to add this information today, but realized that there have been so many changes in the init system, and that network configuration has gotten a lot more complex. I need to figure out what set of scripts to use to create the bridge interface, at the moment I'm inclined to go with the netcfg scripts. Any opinions? -- Jhernberg (talk) 16:40, 24 August 2012 (UTC)
Proposed sections for future expansion of the article
To make the article shorter I move this previously html hidden stuff into the talk page.
Pushing DHCP options to clients
Configuring client-specific rules and access policies
Routing all client traffic through the server
Running an OpenVPN server on a dynamic IP address
Implementing a load-balancing/failover configuration
Locking down security
Security through obfuscation
Port knocking
Running in unprivileged mode
Running in a chroot jail
Larger RSA keys
Enable the 256 bit AES (Advanced Encryption Standard) instead of the default 128 bit blowfish cryptographic cipher:
/etc/openvpn/server.conf
;cipher BF-CBC # Blowfish (default) ;cipher AES-128-CBC # AES ;cipher DES-EDE3-CBC # Triple-DES cipher AES-256-CBC
Revoking certificates
Configuring iptables for use with OpenVPN
Add a rule for the tun devices on both the server and the client.
/etc/iptables/iptables.rules
-A INPUT -i tun+ -j ACCEPT
Add a rule to accept connections on the OpenVPN UDP port (1194) on the server.
/etc/iptables/iptables.rules
-A INPUT -p udp --dport 1194 -j ACCEPT
If you use the iptables firewall on the server (elmer) add the following rules to /etc/iptables/iptables.rules, then restart iptables:
/etc/iptables/iptables.rules
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 10.8.0.0/24 -j ACCEPT -A FORWARD -j REJECT
If you use the iptables firewall on the client (bugs) add the following rules to /etc/iptables/iptables.rules, then restart iptables:
/etc/iptables/iptables.rules
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 10.8.0.0/24 -j ACCEPT -A FORWARD -j REJECT