doc/readme.txt

   1 IPControl
   2 =========
   3
   4
   5 the purpose of ip control is to be a all-consuming ip management solution.
   6
   7 This include firewalling, address management, dns site-to-site vpn (openvpn) and dhcp..
   8
   9 this project will be the first attempt at using xmpp as a source for linux configuration management
  10
  11 this project will essentially turn every linux box connected to the system into a firewall as all rules will be pushed to all boxes... i think...
  12
  13 each box will have control over its ability to route and its interface ip addresses, but thats about it.
  14
  15 Why?
  16 ====
  17
  18 Most of what im trying to do here has been spawned by ipv6. With ipv6 (and more importantly dual-stack ipv6/v4, which will become
  19 common place) the need for a naming structure has become important. Also, the need to manage the address space has become even more
  20 critical cause iana are giving ipv6 addresses like they're candy.
  21
  22 Anyways, when trying to implement dual-stack you get stuck in a situation of having to re-work everything cause you create rules
  23 for ipv4, then another set for ipv6. It gets more complicated by the fact that ipv6 gets a trillion ip's fore each host (ok so i am
  24 exajurating, but what i mean is that you have possibly a real address and a link local address on each interface).
  25
  26 So this software will try and think of everything in terms of names... for eg a host will have a name "host" and a network
  27 might have a name "network", thus to define firewall rules we define either host->network, network->host, host->host or
  28 network->network and then let the infrastructure turn the rules into valid iptables objects.
  29
  30
  31 What we want to be able to do?
  32 ==============================
  33 1) define a host as having dns, dhcp, dhcp-relay, vpn, ipv6, ipv4
  34 2) define networks (ipv6 and ipv4)
  35 3) define hosts
  36 4) connect them all via xmpp
  37
  38
  39 Use Cases
  40 =========
  41
  42 So this little bit will hopefully get people to understand (including myself) what im trying to achieve here.
  43
  44 first we want to be able to define networks, zones and areas.
  45 Networks are just "ranges" we use eg:
  46 - 123.4.5.0/24
  47 - 10.175.0.0/16
  48 - 10.172.0.0/16
  49 - 2001:123:123::0/48
  50
  51 then we want to define the areas where things exist, for eg:
  52 - external (the rest of the world)
  53 - datacenter (our datacenter space)
  54 - clients (where we host stuff)
  55 - office (our office network)
  56
  57 Zones define how we "see" things, for eg:
  58 - external may be a zone called outside
  59 - clients may also be in the outside zone
  60 - datacenter may be internal
  61 - office may be internal
  62 This is used to define who sees what in terms of dns entries. For eg people on the internal zones will see
  63 web01.www.us.int as 10.175.1.2, but on the outside zones as 123.4.5.1 - make sense?
  64
  65 Then we want to define how we associate area's with addresses, for eg:
  66 - 123.4.5.0/24 is our externally addressable space
  67 - 10.175.1-10.0/24 might be our datacenter space
  68 - 10.175.11-20.0/24 might be our client space
  69 - 10.172.1.0/24 might be our office space.
  70
  71 now we want to intelligently allocate things around such that firewall rules are created and the like, for eg:
  72
  73 Lets say i want to deploy a 3 tier web service thats externally accessible via 80 and 443 in our idc. So we go and define
  74 3 new networks in the thing and it should auto-allocate us 3 new ranges (we tell it size, i.e. 255 ip's for each)
  75 We then define 3 web servers with 1 ip each in our "web tier" with the zone name of web.us.int. The softare automatically allocates 3 ip addresses in our
  76 web tier range (lets say 10.175.1.2 web01, 10.175.1.3 as web02 , 10.175.1.4 as web03).
  77 We then say our web servers are accissible as an external address (which is then allocated to us) on ports 80 and 443 as www.ourspace.int
  78
  79 So now the software will go out and do some kewl things (lets assume we want to use dns load balancing). What it will do is:
  80
  81 create 3 dns entries for our external zone called www.ourspace.int pointing at 3 external addresses, 123.4.5.1, 123.4.5.2, 123.4.5.3 and give out each address randomally
  82
  83 then it'll create 3 dns entries for internally facing dns called web01.web.us.int (10.175.1.2), etc.
  84
  85 It'll then automagically create natting rules allowing 123.4.5.1 -> 10.175.1.2 and ip fw rules allowing in-bound traffic on port 80 and 443 to hit our webservers
  86
  87 You can see where im going with this.
  88
  89 Lets look at a mail-router example. So we define a domain a.b.c and say the mx is mx01.a.b.c in area datacenter and zone internal, externally named mx01.a.b.c. The framework
  90 should automatically allocate an external ip address, an internal one on an appropriate network setup the mx records AND publish dns entries as well as NAT and allow access
  91 on port 25 via ip tables to the hosts... make sense? The steps to do this should be:
  92 1. create domain name
  93 2. create server in existing network (which already has a zone and area assocaiated with it)
  94 3. add server as mx for domain.
  95 Yeah, THAT SIMPLE. Thats what we're aiming for here.
  96
  97
  98 gateways and servers
  99 ====================
 100
 101 these are simply machines that are part of our control mechanism. i.e. dns, dhcp, routers etc. (it would be nice to have a build for this)
 102
 103 so like if we say a network has a dhcp range, we should also have to define a dhcp server to hand out addresses.
 104
 105 Server builds
 106 =============
 107
 108 We want our "Servers" that form part of this solution to have a standard (and secure) build. Lets assume redhat/centos 5 as a base (i.e. someone builds a machine with standard redhat)
 109 Then we have a script they run which tightens it up. i.e. disables all the stuff we dont need, adds software we do need. More then just that, but basically the initial script
 110 will just add the software we need for the "Server" to be an xmpp client to our central xmpp server. Then as we define rolls for the server it'll change its config and so forth
 111 depending on its role... i.e. for dns, it'll do a yum install bind, for dhcp yum install dhcpd, etc.