Proposal: Network configuration file format
Here is my proposal for a network configuration file format. It is one
config file containing all data needed for the network configuration.
This includes the interface configuration and routing and firewall
setup. The parsing of the config file will be done by a "smart"
activation agent written in C (there is no code yet, but I will be
working on it ASAP). This agent should figure out reasonable defaults
when some values are not given in the configuration file.
I am writing this proposal as my first try to get Debian a network
configuration that can be easily changed by configuration tools as well
as manually. I am also in contact with Jacques Gelinas (the Linuxconf
developer) with whom I am planning to write a Linuxconf configuration
module and Michael Johnson (from RedHat) who ist interested in using the
firewall configuration part for the RedHat distribution. I would like to
have more cooperation between RedHat and Debian and the firewall setup
could be a start.
This proposal is subject to heavy changes and I encourage everybody to
write comments and critics about the proposal. I want something that is
easy to set up for the beginner but is powerful enough to control neary
every aspect of a Linux network configuration. The main point where I am
not sure is about splitting the information. The data could be in one
big file (as it is now in the proposal) or it could be split into
multiple file, each for its specific purpose.
The file format is taken from BIND 8.x as I find it easy to read and
write.
I am open to any suggestions, this is only the first try. But I want a
network configuration soon, because I am building a Debian based
firewall distribution that needs some configuration tools !
PS: I am not a Debian developer yet, my application is pending for a few
months now...
Proposed config file format for the Linuxconf advanced network module:
Main Sections (from 1 to 4)
1. Global: All definitions that are valid for the whole host.
Any ideas what entries should belong here ?
2. Networks: One network equals one (physical) interface.
[It is named Network because of it seems more natural for new users,
advanced users will know that a network needs an (physical) interface
and
the other way around.]
This section constists of several entries, one per network (aka per
interface). An entry has the format:
network "internal" {
interface "eth0" {
addressv4 10.0.0.2;
addressv6 .................;
}
interface "eth0:0" {
addressv4 10.0.0.5;
}
netmaskv4 255.255.255.0;
broadcastv4 10.0.0.255;
networkv4 10.0.0.0;
}
and the following options (mainly all options taken by "ifconfig") :
- interface: The used interface (e.g.: eth0, isdn0, ppp0, sl0, lo,
...)
- addressv4: The IPv4 address of the interface, can be either a
IPv4
address, "bootp" or "dhcp" or "dynamical" for dialup-connections.
- addressv6: The IPv6 address of the interface.
There can be zero or more interface entries. There can be two
addresses
per interface, one IPv4 and one IPv6 address (see ifconfig man
page:
add), or if kernel 2.2.x is used, any number of addresses can
be used per interface (see "ip" command documentation).
All interfaces in one network entry share the same netmask and
broadcast
and network address as they are on the same physical network.
This feature will be useful for virtual servers.
If there is no interface definition, it is only a named network
where
at least the netmask and network address have to be given. Named
networks are used for defining routing and firewall targets.
- netmaskv4 / netmaskv6: The network netmasks.
- broadcastv4 / broadcastv6: The broadcast addresses.
- networkv4 / networkv6: The network addresses.
The must be at least either a IPv4 or a IPv6 definition for the
primary
interface. The use of both address formats is possible and
encouraged for
the next years until the transition to IPv6 is completed.
- ptpaddressv4: When the interface is a point-to-point interface,
the
address of the other end.
- ptpaddressv6: The IPv6 address of the other end.
Optional parameters:
- enabled: Can be set to true or false, default is true. This can
be used
to temporarily disable an interface if set to false.
- arp: true or false (see ifconfig man page)
- allmulti: true or false (see ifconfig man page)
- metric: see ifconfig man page
- mtu: see ifconfig man page
- tunneldest: Has to be after an IPv6 address line and specifies
the
destination of the (optional) IPv6-in-IPv4 tunnel.
- irq: The dynamically changeable IRQ if supported by the device.
- io_addr: The I/O address if supported by the device.
- mem_addr: The memory address if supported by the device.
- media: The used media (e.g. 10baseT or 10base2).
- bandwidth: The maximum bandwith for a interface (see iproute2+tc
docu).
- setdefaultroute: Sets the default route to point to the
interface.
This can be used for very easy setups, such as ppp-only connected
hosts.
Can be True, False or onconnect.
maybe in future enhancements:
- ipx address
- appletalk address
- PPP / ISDN options (I would prefer this one to be implemented
first)
- .......
3. Routing: Routing table entries. All routing entries for the specified
interfaces are done automatically and should not be given here.
Routing classes are:
- default:
route default {
gatewayv4 10.0.0.1;
metric 1;
}
route default {
gatewayv4 10.0.0.36;
metric 2;
}
A gateway address can be followed by a metric that is used for
the
route. Add one entry per default route.
- routes to named networks:
route "external" {
gatewayv4 10.0.0.154;
metric 1;
}
route "external" {
gatweayv4 10.0.0.65;
metric 2;
}
- routes to hosts:
route "10.0.1.3" {
gatewayv4 10.0.0.79;
}
- bridges between networks:
bridge "virtualnetwork" {
from "internal";
to "external";
}
I never used Linux bridging, so I have no knowledge about the
possible
features.
Options for routing entries (this should cover all new 2.2.x
capabilities):
- I will go through the "ip" command documentation and try to build
a
list of current kernel 2.2.x features. This will take me a few
days
but I think the general routing concept stays they same, there
will just
be more options similiar to firewalling.
4. Firewalling:
This section contains firewalling rules (see ipchains manual page for
details).
rule {
from "internal";
to "external";
masquerade;
}
could be written in the form
rule { from "internal" to "external" masquerade }
Possible parameters for a firewalling rule are:
- from: Zero or more can be given. If there are more than one from
fields,
more than one rules will be added to the kernel filter
accordingly.
- to: see from
If no from parameter is given, all source hosts match the rule. The
same
goes for to parameters. Values of these parameters can either be
named
networks or hosts (given by IP address or FWDN).
- forward: Directly forward packages between all "from" and "to"
hosts /
networks.
- masquerade: Masquerade the connections.
- deny <direction>: Skip packets matching the other parameters.
- reject <direction>: Reject (send ICMP reply to sender) matching
packets.
- accept <direction>: Accept matching packets.
Where <direction> is either incoming or outgoing.
- log: Log all packets matching the rule into the syslog.
- monitor: Copy all matching packets to the netlink device. This
enables
monitoring of active connections with a separate package (I will
write a
little daemon that listens for TCP connection start and end
packets and
provides a list of active TCP connections on request.).
- protocol: Can be either "tcp", "udp" or "icmp".
- firstpacket: Matches only the first packet of a TCP connection
(with the
SYN bit set).
- fragment: Matches a fragment of a TCP packet that is NOT the first
fragment (and therefore that is not containing the IP header
fields).
- redirect: Use port forwarding to a specific host.
- transproxy: Redirect to a local port (transparent proxying).
- bidirectional: Create a second rule with exchanged "from" and "to"
values.
- options for setting the TOS field and marking the packets on the
way
All options can be preceeded by "not", inversing the parameter
value.
A spoof protection is set up automatically for all interfaces.
5. Examples
5.1 An example as I would use it for my home network:
# The local network.
network "internal" {
# The main connection to the internal network.
interface "eth0" { addressv4 10.0.0.4 }
# This is for testing apache's virtual server capabilities
interface "eth0:0" { addressv4 dhcp }
networkv4 10.0.0.0;
netmaskv4 255.255.255.0;
broadcastv4 10.0.0.255;
}
# a direct connection to a other local network that provides some
services
network "untrusted" {
interface "eth1" { addressv4 192.168.1.34 }
networkv4 192.168.1.0;
netmaskv4 255.255.254.0;
broadcastv4 192.168.2.255;
}
# For using Vmware's network capabilities.
network "vmnet" {
interface "vmnet0" { addressv4 10.0.1.1 }
networkv4 10.0.1.0;
netmaskv4 255.255.255.0;
broadcastv4 10.0.1.255;
}
# The ISDN connection to the outside
network "isdn" {
interface "isdn0" {
addressv4 193.170.191.36;
ptpaddressv4 193.170.191.33;
}
networkv4 193.170.191.32;
netmaskv4 255.255.255.240;
arp false;
# A shell script sets this to true if I want automatic connections to
be made
enabled false;
# Maybe we should put in the ISDN settings here too (telephone number,
# protocol, ...)
}
# PPP dialins
network "dialin" {
interface "ppp0" {
addressv4 10.0.2.1;
ptpaddressv4 10.0.2.2;
# I do not want dialins to saturate my ISDN connection.
bandwidth 14400;
}
interface "ppp1" {
addressv4 10.0.2.3;
ptpaddressv4 10.0.2.4;
bandwidth 14400;
}
netmaskv4 255.255.255.240;
networkv4 10.0.2.0;
arp false;
}
# A named network for the firewalling rules
network "internet" {
networkv4 0.0.0.0;
netmaskv4 0.0.0.0;
}
# The default route to the internet
route default {
gatewayv4 193.170.190.33;
}
# Now some firewalling rules
# masquerade the internal network to the internet, but do www access
over a
# (transparent) proxy on the local host
rule { from "internal" to "internet"/www
protocol tcp;
transproxy 8080
}
rule { from "internal" to "internet" masquerade }
# port forwarding to the internal ftp server
# everywhere/ftp means 0.0.0.0/0 port 21
rule { from "internet" to everywhere/ftp
protocol tcp;
redirect 10.0.0.24
}
rule { from "dialin" to "internet" masquerade }
# Only provide internet access but do not allow local network access
rule { from "dialin" to "internal" reject incoming }
# allow connections to the untrusted network but not the other direction
rule { from "internal" to "untrusted" forward }
rule { from "untrusted" to "internal";
firstpacket;
deny incoming;
log;
}
5.2 A simple masquerading-only example would look like this:
network "internal" {
interface "eth0" { addressv4 10.0.0.2 }
netmaskv4 255.255.255.0;
# network and broadcast adresses are determined by interface address
and
# netmask, but could be overridden here
}
network "dialout" {
interface "ppp0" {
addressv4 dynamical;
ptpaddressv4 dynamical;
}
# all other values are figured out by the "smart" activation agent
setdefaultroute onconnect;
}
rule { from "internal" masquerade }
Reply to: