|
|
On Wednesday 11 August 2004 12:05, Jim Carter wrote: > On Tue, 10 Aug 2004, James Yonan wrote: > > I have a counterproposal on how to simplify the "mode server" config. > > (snip) > > The "server" option would operate like a macro, for example: > > > > server 10.8.0.0 255.255.255.0 > > > > expands to the following set of directives: > > > > mode server > > tls-server > > > > if tun: > > ifconfig 10.8.0.1 10.8.0.2 > > ifconfig-pool 10.8.0.4 10.8.0.255 > > This looks like a good idea. However, beware of 10.8.0.255. If > 10.8.0.0/24 is a meaningful subnet on the server, that will be the > broadcast address for that subnet. When the server intends to broadcast, > are the packets hijacked by the more specific 10.8.0.252/30? Or vice > versa? Best not to tempt fate; do put in a special kludge to avoid > broadcast addresses that are already in use, or might be used in the future Right, probably the last /30 subnet should be considered reserved, and not be passed to any clients. > Earlier you discussed inflexible hardwired setups... How about a *real* > macro capability? Here's an example: > > macro <itsname> # The arguments are implicitly named %A %B... > (stuffing of macro) > endmacro > > The %A thingies would have an extension: %<integer><letter> means add the > optionally signed integer to the last group of digits in the value. So to > implement the "server" thing above (which could be predefined for user > convenience, except for the four-way conditionalization which would be > really nice if it were more than an expository decoration): > > macro server # Comment: %A = ifconfig-pool base, %B = its mask > mode server > tls-server > if tun: > ifconfig %+1A %+2A > ifconfig-pool %+4A %+251A > route %A %B > if client-to-client: > push "route %A %B" > else > push "route %+1A" > endmacro > > For the ultimate in flexibility, multi-octet "integers" could be > considered. I can hear you groaning already, metaphors of worms in a can > ringing bells and blowing whistles... Anyway, it was a thought. Yeah, right. I must say I don't have a huge enthusiasm for adding shell-like features to the OpenVPN config file grammar. One of the reasons why every config file parameter can also be a command line parameter (with '--' prepended) is so you can instantiate OpenVPN with dynamically generated arguments from any shell or scripting language. This should give you all of the flexibility you need without needing to bloat down OpenVPN with yet another config file grammar. One other downside of using a user-defined macro as you've written above is that if there are errors in the parameters supplied by the macro, it will be harder for OpenVPN to give a meaningful error message because the error will be thrown when the expanded directives are processed. So the user will see an error about ifconfig-pool parameters being wrong when they don't have ifconfig-pool in their config file. Other checks, such as not allowing certain directives which conflict with "server" become more difficult because then they must be incorporated into the macro language. Of course the solution to that is to add a macro debugger as well to OpenVPN :) James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |