| Author: | John M. Gabriele |
|---|---|
| Date: | May 2007 |
| Back to: | homepage |
"The Net interprets censorship as damage and routes around it." -- John Gilmore (EFF)
These are some of my rough notes on general networking concepts. They're here as a 10,000-meter view of networking. For more of the real story, start by having a look at the relevant portion of the Debian Reference: http://www.debian.org/doc/manuals/reference/ch-gateway.en.html. Then you might look for specific articles at http://www.debian-administration.org/. Finally, be sure to read the relevant man pages. Of course, it should go without saying that there's also various useful networking how-tos at tldp.
Please note that there is some duplication here. The reason is because I like each section to be as helpful as possible all by itself.
To quickly get up to speed, have a look at the netfilter networking basics howto. That said, here's a few core notes to keep in-mind:
A host is a computer running ("hosting") a TCP/IP network stack. The NIC drivers make up the bottom-most part of the stack. One host can have more than one NIC (which would make it "multi-homed"). Sometimes a single device plugged into a network is called a "node".
"Packet" is a generic term which can mean segment, datagram, message, or frame, depending on context.
Nodes connected together via hubs, switches, or even just old-style coax are considered to be "on the same wire". When you send a broadcast packet, everyone who gets that packet is "on the same wire" as you.
Gateways (Internet routers) route packets between networks. When a multi-homed host forwards packets, it's acting as a router.
Packets don't have any netmask information in them. Netmasks are stored in a host's routing table and are specific to each NIC. A gateway looks at a packet's IP address, then plugs that address into its routing table -- applying each netmask as it ripples down through the rows of the table -- to see which network it's headed for, and thus where to forward that packet to.
Layer 4: "Application layer" DNS, PPP, FTP, HTTP, DHCP, POP, SMTP, OSPF, NFS, etc. ^ | | Layer 3: "Transport layer" TCP segments, UDP packets, ICMP messages ^ | | Layer 2: "Internet layer" (iptables) IP datagrams, ARP ^ | | Layer 1: "Network Access layer" (aka "link layer") (ebtables) Ethernet frames
Recall, the top layer is (bit-wise) the smallest. As an example:
+------------+------------------------+
| TCP header | Application layer data |
+------------+------------------------+
+-----------+-------------------------------------+
| IP header | payload (TCP packet) |
+-----------+-------------------------------------+
+-----------------------+-------------------------------------------------+
| Ethernet frame header | payload (IP packet) |
+-----------------------+-------------------------------------------------+
Package name and available man pages for the major network-related packages:
Other man pages to read: networks
The ip command (in the iproute package) is supposed to have replaced the ifconfig and route commands by now. I'm running Debian Etch here, and by default I don't have iproute installed. The ip command is more capable (and looks to me to be easier to use) than what it's replacing, but many folks are comfortable with ifconfig and route. For docs on iproute (sometimes called "iproute2"), see http://lartc.org/.
Old commands:
At the highest level, you start/stop/restart system-wide networking using /etc/init.d/networking {start|stop|restart|force-reload}. This script calls the ifup/ifdown commands.
Now and again, for individual interfaces, you may instead want to use something like the following:
ifdown eth0 vim /etc/network/interfaces # Maybe tweak this file. ifup eth0
The ifup and ifdown commands configure network interfaces as specified in the /etc/network/interfaces configuration file. If you've got a static IP address, that interfaces file might look like:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.0.0.44
netmask 255.255.255.0
gateway 10.0.0.86
See man interfaces for more details.
If you have to, and you know what you're doing, you can use the ifconfig command by-hand:
ifconfig eth0 inet down
When the kernel has a packet that needs to be delivered (either one that a local app pushed onto the stack, or else one that just came in from the NIC) it looks at its routing table to see what to do with it. Routing information is stored in a table in the Linux kernel. You use the iptables command to access this routing table (XXX Wait. What about the route command? XXX). To set up routing on a GNU/Linux box, you typically run a script (at startup) containing a bunch of iptables commands like:
#!/bin/bash iptables --this iptables --that iptables --the-other-thing echo 1 > /proc/sys/net/ipv4/ip_forward echo "Routing is now configured."
For more about iptables, see http://www.netfilter.org. They've got excellent docs there.
IPv4 net addresses are 32 bit, and by convention are written with dots separating bytes:
00000000.00000000.00000000.00000000
0 . 0 . 0 . 0
11111111.11111111.11111111.11111111
ff . ff . ff . ff
255 . 255 . 255 . 255
They're logically split into network address and host address:
Notation: /n means that the first n bits are for the network name. Here is a table of network masks: Short Full form Maximum # of Comment Form Machines /8 /255.0.0.0 16,777,215 Used to be called an "class A" /16 /255.255.0.0 65,535 Used to be called an "class B" /17 /255.255.128.0 32,767 /18 /255.255.192.0 16,383 /19 /255.255.224.0 8,191 /20 /255.255.240.0 4,095 /21 /255.255.248.0 2,047 /22 /255.255.252.0 1,023 /23 /255.255.254.0 511 /24 /255.255.255.0 255 Used to be called a "class C" /25 /255.255.255.128 127 /26 /255.255.255.192 63 /27 /255.255.255.224 31 /28 /255.255.255.240 15 /29 /255.255.255.248 7 /30 /255.255.255.252 3
(I think I borrowed this table from the netfilter docs, but then changed its formatting a bit.)
Linux looks at the routing table when it has a packet to forward. Either one came in over the wire, or else a program on your local system is sending one out. Either way, the TCP/IP stack looks at the IP address it's headed for and then figures out which network to route it to. That is, it grabs the destination IP, then for each row in the routing table, applies the netmask to it and compares that number with the "Destination" network's IP to see if they match. If they do, off it goes to that Iface.
To get a packet to "Destination" (which is a network, not a host), send it to a certain "Gateway".
Example output (box set up for ppp dialup):
[john@quartz /etc]$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 205.198.xx.xxx 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lo 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 205.198.xx.xxx 0.0.0.0 UG 0 0 0 ppp0
(xx.xxx was put in in lieu of the real numbers.)
If gateway says 0.0.0.0, that means deliver locally. In this example, to get a packet out to 205.198.xx.xxx/32, just deliver it directly right out from ppp0. Note, for 205.198.xx.xxx, the whole IP address is all network and no host.
Same goes for packets that just came in on 'lo'.
For all other packets, the default route is 205.198.xx.xxx -- that is, right out the modem.
(Note that the 169.254.0.0/16 network seems to have something to do with zeroconf I believe.)
Here's a very simple (and common) example, from a machine connected to router through it's (only) ethernet port:
avocado:~# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
This machine is 192.168.1.101.
If a program on my machine says to send a packet to 192.168.1.101, I'm pretty sure that it sends the packet down the stack. At the point where the routing table is consulted, rather than "deliver locally" (which would mean to grab the MAC address for 192.168.1.101 and send the ethernet frame out onto the wire), I think the stack is smart enough to simply send the packet back up to be handed off to the correct port.
From RFC1918:
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
You choose one of those three network addresses (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) for your private network's address. If you work at a giant company, choose the 10.0.0.0. From there you can subdivide your network into subnets if you like. (See discussion of subnets below.)
Use the "route" command to configure the routing table. Ex.:
route add -net n.n.n.n netmask m.m.m.m gw p.p.p.p eth0 route add default gw q.q.q.q eth1
("gw" is for gateway -- a hostname. -net is telling route that you're adding a network to a network rather than an individual host. n.n.n.n is the destination network.)
Of course, all this is for "static routing". If you've got a host on a network that changes often, you want to enable dynamic routing instead (see gated and routed).
Yes, it does look weird that "route" is for setting routes however "netstat -rn" is for viewing the routing table. :) Actually, you may view the routing table using either 'netstat' or 'route'.
Summary of some routing-related commands:
When a packet comes to your machine, it is directed at a given port. That port needs some program listening on it, or else the connection to your machine will be refused (note the mixing of terminology here: individual packets make up a TCP "connection").
You can either have a bunch of daemons/servers/programs running on your machine, each listening to its own port, or you can have one "telephone operator" style program that waits for a request, and starts one of those daemons only when a request comes in for it.
The name of that telephone operator program is "inetd" (or, on newer Redhat systems, "xinetd").
Daemons that service lots of requests all the time (like sshd or httpd) are left running continuously and don't use inetd. Daemons that only get a request once in a while usually are set up to use inetd. See /etc/inetd.conf for all the services that inetd is managing for you. See /etc/init.d for the ones that run all the time.
If you want a middle-man between inetd and the various programs it manages, you want tcp_wrappers (aka "tcpd"). tcp_wrappers is simply an authentication mechanism . See /etc/hosts.allow. tcp_wrappers comes in the tcpd package. It was written by the same fellow who wrote Postfix. When using it, in your /etc/inetd.conf file, instead of programs being called directly, you'll see calls to tcpd instead.
Every new TCP connection (like, say, one initiated by you from your browser window/tab when clicking a link) gets a different "source port", so everyone can tell them apart, even if they are going to the same destination IP address and the same destination port. Source ports usually begin at 1024 and go up by one for each subsequent TCP connection.
DNS (Domain Name System) is for mapping names to IP addresses. DNS uses UDP, and the most common implementation of DNS is called BIND (for Berkeley Internet Name Domain) and the daemon is named named.
To manually keep track of a small number of hostnames, you might put entries into your /etc/hosts file.
Put the IP address(es) of your name servers in /etc/resolv.conf.
Besides just storing IP <--> hostnames, DNS also stores "MX records":
something@domain.com --(gets sent to)--> mail.domain.com
Some DNS-related commands:
If you have bind installed, see your /etc/bind/named.conf.
From http://www.debian-administration.org/articles/23:
You can also install a local nameserver to cache DNS lookups and allow you to recognise your internal machines.
A great package for this is dnsmasq. This can be installed via apt-get and is configured via a simple readable file /etc/dnsmasq.conf.
promiscuous mode
The two tools you'll want to use are:
Wireshark and tcpdump use the same library (libpcap), but Wireshark doesn't wrap tcpdump.
You can collect the output from tcpdump, and import it into Wireshark if you like.
Of course, sniffing won't get you anywhere if you're trying to see what's happening on an https stream, as all you'll see is the encrypted traffic.
Also, possibly have a look at the poorly-named GUI tool called "etherape". There's also a text version of etherape called iftop http://www.ex-parrot.com/~pdw/iftop/.
Maybe also see:
Maybe have a look at
Links:
DHCP uses UDP.
On Debian, you'll already have the client package installed: dhcp-client. See man <dhclient|dhclient.conf|dhclient-script> for more details.
When your Debian system boots up, if an interface is configured (see /etc/network/interfaces) to use dhcp, then, at startup, when XXX is run,... (to do).
apt-cache show dhcp
See my ssh notes.
A subnet is simply a bunch of hosts that are all configured to have the same network address for local delivery. Hosts know (by looking at their routing table) what network, and subnet, they are on.
You could have computers on the same LAN (on the same wire) configured to be on different subnets, but then every time one on one subnet wanted to talk to one on another subnet, it would have to send the packets to a gateway first (even though the other computer sees the packet go by on the wire), and then the gateway would send the packets on to the other subnet. This isn't very efficient, and I don't yet see a use for it.
If you have a building with a large number of computers in it, and you want to compartmentalize the network, you can't just drop in a router, plug a switch into it, and start plugging computers into that switch, all the while still naming your hosts 192.168.n.m as if they were all still on a 192.168.0.0/16 network. The router routes packets between networks. You hafta have a different network on each side of that router (it's usually got two sides: one that the switch plugs into for this group's computers, and the other where it plugs into the rest of the network) so it can route packets between them.
That 192.168.0.0/16 network is just one network. Same with 10.0.0.0/8, or 172.16.0.0/12. But you need multiple networks if you want to start dropping routers into the mix. That's the whole point of subnetting.
Now you can see why you (the netadmin) can hijack some of the host address bits of an IP address and use them as a subnetwork address. You just have to make sure all your host's routing tables are configured accordingly.
Another key to understanding subnetting is what was stated near the top of this article: packets don't have any netmask information in them. When a host forwards a packet, that's when it uses netmasks (which are associated with routes in the routing table) to determine the network the packet needs to go to. When one host inside your organization sends a packet to another host, the packet should have an rfc1918 address on it. When that packet gets tested against one of your router's routing tables, the truth comes out as to which subnet it's destined for.
See also: RFC 1878 -- Variable Length Subnet Table For IPv4
When you build a server computer to act as a gateway, you usually put in two NIC's. Having more than one network connection on one box is called "multihoming". Such a server is said to be "multi-homed".
But the Linux kernel lets you pull a trick of assigning more than one IP address to a single real network interface (ex. an NIC with only one ethernet port on it). That trick gets you a number of so-called "virtual network interfaces", or just "virtual interfaces" for short. (I think the older term for this was "IP aliasing".) When you see an interface with a name like eth0:1, eth0:2, etc., that's a virtual network interface.
The networking overview howto says IP aliasing is typically used for:
...services that act differently based on the address they listen on (e.g. "multihosting" or "virtual domains" or "virtual hosting services".
I think this may be used for Apache's so-called IP-based virtual hosts. Though, you're probably better off just using name-based virtual hosts. After all, why waste publicly-addressable IP's?
A quick summary of some config files in /etc that are relevant here: