|
← Revision 2 as of 2004-07-02 14:39:56
Size: 2587
Comment:
|
← Revision 3 as of 2004-07-02 14:41:15 →
Size: 2586
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 34: | Line 34: |
| Now this situation will scale up to 25 SuperNodes for the exsisting VPN IP block. This should be plenty enough for the initial setup of the core VPN network. Thinking ahead having more than 25 SuperNodes is a great possibility, so the Idea of having a few extra reserve 24 bit subnets might have to come into consideration. Zeroconf was also an option if the tap interfaces are tested with it in a OpenVPN tunnel. | Now this situation will scale up to 25 SuperNodes for the exsisting VPN IP block. This should be plenty enough for the initial setup of the core VPN network. Thinking ahead having more than 25 SuperNodes is a great possibility, so the Idea of having a few extra reserve 24 bit subnets might have to come into consideration. Zeroconf is also an option if the tap interfaces are tested with it in a OpenVPN tunnel. |
OpenVPN IP Scheme Proposal
As a Proposal for VPN IP address scheme, an organized mapping for tun interface IPs in the reserved VPN IP block would be required to make managing tunnels easier. It is still untested for direct tunnels off shared tap devices so the ability to map them efficiently and logically would be most preferred. BR The PTPnet IP block of 10.11.255.0/24 is already reserved for this idea. Right now in the basic stages of the network the IP addresses are just paired in two between the core servers and the "SuperNodes". As for each SuperNode will require its own tunnel to each server, I believe it would be a good idea to group the IP addresses that are for each SuperNode. Note that this example would be used only for the links between the Core servers and each SuperNode.
Example:
Core Servers |
|
10.11.255.1 |
<=> |
10.11.255.6 |
10.11.255.2 |
<=> |
10.11.255.7 |
10.11.255.3 |
<=> |
10.11.255.8 |
10.11.255.4 |
<=> |
10.11.255.9 |
10.11.255.11 |
<-> |
10.11.255.16 |
10.11.255.12 |
<-> |
10.11.255.17 |
10.11.255.13 |
<-> |
10.11.255.18 |
10.11.255.14 |
<-> |
10.11.255.19 |
10.11.255.21 |
<=> |
10.11.255.26 |
10.11.255.22 |
<=> |
10.11.255.27 |
10.11.255.23 |
<=> |
10.11.255.28 |
10.11.255.24 |
<=> |
10.11.255.29 |
BR Now with only having roughly one SuperNode for each 10 IP addresses seems excessive but between having upto 5 core servers (only 3 are now used but the ability to add two extra servers would be good planning) and using a base 10 counting between SuperNodes allows for an administrator to easily figure out what SuperNode the core servers are tunneled with just by the IP pair. BR Another reason to have extra IP pairs possible between the group of Core IPs and SuperNode IPs would be if direct links via wireless or a different ISP was provided for failsafe tunnels that could be made between the SuperNodes and the Core Servers. BR Now this situation will scale up to 25 SuperNodes for the exsisting VPN IP block. This should be plenty enough for the initial setup of the core VPN network. Thinking ahead having more than 25 SuperNodes is a great possibility, so the Idea of having a few extra reserve 24 bit subnets might have to come into consideration. Zeroconf is also an option if the tap interfaces are tested with it in a OpenVPN tunnel.
References:
http://openvpn.sourceforge.net/
Creator: JimmySchmierbach