Anyway, even though I might not be the most active blogger on this side of Indus, this one should be useful to some people for now and probably some time forward.

As most people* know, Cisco IPSec VPN and 64-bit operating systems aren’t best friends, since Cisco wants people to use their Anyconnect client for licensing reasons, and decided to never make a 64-bit version. So, since I use IPSec for most of my VPN connections, and I don’t want to be stuck in a 32-bit world forever, I spent some time getting it to work om my workstation. *) Most people = Network guys.

The components I used for testing was a Cisco 3000 VPN Concentrator (although it should work with PIX and ASA as well) and MacOS X Lion 10.7 (now also confirmed working on the 10.7.1 update). Basicly, most of this stuff should work on clients of any UNIX flavor, with the exception of some path names and the Applescript.

The instructions are written in a way that even users not familiar to UNIX environments should be able to pull it off, which makes them look kind of childish for an experienced UNIX guy, but you can’t make everybody happy, can you?

Downloads

All software you need to download for this is listed here. You don’t have to download these now, you can do it along the way further down, but starting that Xcode download could be a good thing, since it is 3GB big.

http://itunes.apple.com/us/app/xcode/id448457090?mt=12#
ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.9.tar.bz2
ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2
http://sourceforge.net/projects/tuntaposx/files/tuntap/20090913/tuntap_20090913.tar.gz/download
http://www.unix-ag.uni-kl.de/~massar/vpnc/vpnc-0.5.3.tar.gz
http://www.ithora.se/public/software/macos-vpnc/vpnc-fix
http://www.ithora.se/public/software/macos-vpnc/vpn/launcher.command
http://www.ithora.se/public/software/macos-vpnc/VPN%20Actions.scpt

General information:

Open a terminal and type:

whoami

Record your MacOS username. Everywhere you see “pbodin” in this document, replace it with either your MacOS username, or your VPN username (in my case, both are pbodin).

When you use the sudo command throughout this task, it might ask for your password. Then feed it with your MacOS password.

There might be newer versions of the software used in these instructions. Feel free to try the newer versions. Your mileage may vary, and I’ve only tested this with the versions mentioned below.

Tip for the non-frequent vi users: If you screw up inside vi, press ESC a couple of times and type :q! to get out of vi without saving, and then start over from the vi command. Or read this: http://www.cs.colostate.edu/helpdocs/vi.html

All commands you’re supposed to type in a terminal or something are in italic font. Beware that this page wraps the lines, so use copy and paste to make sure to have your newlines in order.

The setup redirects all non-local traffic through the VPN tunnel (i.e. no split-tunneling). Also, local DNS will cease to work, all queries will end up on the DNS servers provided by the VPN connection. All this can easily be changed within the script, if you know how to.

Install a compiler

The easiest is to download Xcode from App Store: http://itunes.apple.com/us/app/xcode/id448457090?mt=12#

The download is 3 GB though, so if you’re on a slow connection and know what you’re doing, you might choose to get a standalone gcc or similar instead.

Install libgpg-error

Open a terminal and type:

curl -o libgpg-error-1.9.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.9.tar.bz2
tar -zxvf libgpg-error-1.9.tar.bz2
cd libgpg-error-1.9
./configure
make
sudo make install

Install libgrcypt

Open a terminal and type:

curl -o libgcrypt-1.5.0.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2
tar -zxvf libgcrypt-1.5.0.tar.bz2
cd libgcrypt-1.5.0
./configure
make
sudo make install

Install tuntap

Open a terminal and type:

curl -o tuntap_20090913.tar.gz http://downloads.sourceforge.net/project/tuntaposx/tuntap/20090913/tuntap_20090913.tar.gz?r=&ts=1314366011&use_mirror=surfnet
tar -zxvf tuntap_20090913.tar.gz
open tuntap_20090913.pkg

This will open a GUI installation. Accept all defaults during the installation, and then return to the terminal and type:

sudo /Library/StartupItems/tap/tap
sudo /Library/StartupItems/tun/tun

Install vpnc

Open a terminal and type:

curl -o vpnc-0.5.3.tar.gz http://www.unix-ag.uni-kl.de/~massar/vpnc/vpnc-0.5.3.tar.gz
tar -zxvf vpnc-0.5.3.tar.gz
cd vpnc-0.5.3
vi Makefile

Press / (shift+7) to get a search prompt, enter OPENSSL_GPL_VIOLATION as search phrase and press return.

Place the cursor above the # in the beginning of the line, and then press x to delete the # character. Do this on these two lines:

#OPENSSL_GPL_VIOLATION = -DOPENSSL_GPL_VIOLATION
#OPENSSLLIBS = -lcrypto

Type :wq to save the file and exit vi.

vi sysdep.h

Press / (shift+7) to get a search prompt, enter defined(__APPLE__) as search phrase and press return.
Press o to get in edit mode and start a new line.

Add this line below the APPLE line:

#define HAVE_GETLINE 1

Press ESC to get out of edit mode, and type :wq to save the file and exit vi.

make
make install

sudo vi /etc/vpnc/vpnc-script

Press / (shift+7) to get a search prompt, enter d.add Router as search phrase and press return. You should end up on this line:

# d.add Router $INTERNAL_IP4_ADDRESS

Place the cursor above the # in the beginning of the line, and then press x to delete the # character.

Press ESC to get out of edit mode, and type :wq to save the file and exit vi.

Make vpnc runnable by a normal user (you):

sudo visudo

This starts vi and loads the file /etc/sudoers

Press G (shift+g) to get to the bottom of the file.
Press o to get in edit mode and start a new line.

Add this line:

pbodin ALL = NOPASSWD: /usr/local/sbin/vpnc, /usr/local/sbin/vpnc-disconnect, /usr/local/sbin/vpnc-fix

Where pbodin is replaced by your MacOS username.

Press ESC to get out of edit mode, and type :wq to save the file and exit vi.

Convert pcf profiles

Copy your pcf profile(s) into your Documents folder.

Open a terminal and type:

cd /etc/vpnc
sudo cp /Users/pbodin/Documents/filename.pcf .
sudo pcf2vpnc filename.pcf > filename.conf

Replace pbodin with your MacOS username and filename.pcf with the actual filename. Repeat the two sudo commands for every pcf file you want to convert.

Launch the VPN connection:

Open a terminal and type:

sudo /usr/local/sbin/vpnc –local-port 0 filename.conf

If you get an error saying DES is insecure, instead type:

sudo /usr/local/sbin/vpnc –local-port 0 –enable-1des filename.conf

If it still fails, type this to get more information:

sudo /usr/local/sbin/vpnc –debug 2 –local-port 0 –enable-1des filename.conf

In all three cases with the actual filename instead of filename.conf.

To disconnect, type:

sudo /usr/local/sbin/vpnc-disconnect

If the connection gets dropped without you disconnecting using the command above, you might have to turn Wi-Fi off and on again (or pull the ethernet cable and put it in again) to get Internet working again. Or you can use the provided vpnc-fix script, that fixes this problem at least on my machine. Do this by typing:

sudo /usr/local/sbin/vpnc-fix

VPN fixer

If your computer goes to sleep while connected to VPN, or if you lose the VPN connection by some other magical reason, you’re network might end up in limbo. The you need to fix the routing and DNS settings to get things to work again. This might be done by turning your network on and off again, it might be done by changing location to something else and back again and it can definitely be done by rebooting or fixings things manually.

But just for you my friends, I created a script that does it for you. Download it here: http://www.ithora.se/public/software/macos-vpnc/vpnc-fix and put it in /usr/local/sbin/

VPN launcher

I’ve included a terminal based VPN-launcher written in perl, that you can use if you have several profiles to choose from, and for instance wants to create an icon in your dock or similar. It also has a disconnect option. Download it here: http://www.ithora.se/public/software/macos-vpnc/vpn-launcher.command and put it in /usr/local/sbin

Menu bar menu

There’s a GUI! I’ve written an Applescript file. Put it in /Users/pbodin/Library/Scripts or /Library/Scripts (create the Scripts folders if they’re not already existing). Then start Applescript Editor (under Utilities) and check the Show script menu in menu bar option. If you put the files in /Library/Scripts you also need to check the Show computer scripts option. I prefer to have that option unchecked and keep the scripts in my user scripts folder, to limit the menu size (there’s a whole bunch of system scripts in the computer scripts folder).

This gives a small paper roll like menu item in the menu bar, with the “VPN Actions” script as an option. It will check if there are any active VPN connections. If there are, it will show you the active commands for these (which tells you the VPN server, your username and similar), and ask you if you want disconnect them, connect another connection or if you just wanted to know.

If there are not, it will ask you if you want to connect to VPN, fix a lost VPN connection limobo or if you just wanted to know.

If you choose to connect, the script will ask you for what profile file you want to use. If there is a username and/or password included in the profile file you choose, it will use them, and if not, it will ask you for the information.

It should work with profile files with spaces in the name. It should work with passwords including strange characters (except “). But neither is tested.

There’s some basic error handling (process existance) in the script, but if things go wrong, you’re probably better off if you’re one of those that are able to troubleshoot manually on your own. If you’re not – reboot and try again.

You could also edit the connect script to automatically include your information, eliminating the need to answer the prompts. However, I would recommend keeping the prompt for the password.

Download the Applescript here: http://www.ithora.se/public/software/macos-vpnc/VPN%20Actions.scpt and put it in your Scripts folder.

Credit

I wrote the Applescript and parts of the perl launcher. All other code is written by other people, and all I did was combining them to get it to work. Afaik, all involved tools are open source.

Disclaimer

This how-to is written without any trace of support commitment or endorsement from my employer as a company or me as the author. And if it makes your computer blow up, you alone were the one pressing the enter key. I will of course try to help you if you get stuck and I have the time, but without commitments.

I think I got all actions I had to do into this how-to, but I might have missed something. If you get stuck, send me an email or catch me on Skype, and I’ll try to recall what I did.

Subject: Re: [networking] Reverse DNS

MA> Det finns “classless reverse-DNS”, dvs de kan delegera vidare subnät som
MA> är mindre än /24. Det finns en RFC som behandlar detta, jag är inte 100%
MA> säker på hur det fungerar (jag har har aldrig behövt göra det) men det
MA> involverar att man lägger upp 64 st IN NS (eller om det var CNAME) när det
MA> gäller reverse-dns som sen pekar på kundens DNS. Typ:
MA>
MA> 0-63.209.85.195.in-addr.arpa. IN NS kund-dns.domän.se
MA> 1.209.85.195.in-addr.arpa. IN CNAME 1.0-63.209.85.195.in-addr-arpa.
MA> 2.209.85.195.in-addr.arpa. IN CNAME 2.0-63.209.85.195.in-addr-arpa.
MA> 3.209.85.195.in-addr.arpa. IN CNAME 3.0-63.209.85.195.in-addr-arpa.
MA> 4.209.85.195.in-addr.arpa. IN CNAME 4.0-63.209.85.195.in-addr-arpa.

Jag kör reverse via CNAMES i flera steg. Det funkar såhär:

Reverse DNS vänder ju på adressen och lägger dit in-addr.arpa på slutet, så att
195.42.219.125 blir 125.219.42.194.in-addr.arpa, sedan fungerar det i princip
som “vanlig” DNS, fast med toppdomänen .arpa

195.42.219.0/24 handhas utav Wineasys DNS-server. Alltså ser NS-record och SOA
för domänen 219.42.219.in-addr.arpa ut såhär:

219.42.195.in-addr.arpa. IN SOA ns.wineasy.se. registry.wineasy.se.
219.42.195.in-addr.arpa. IN NS ns.wineasy.se.
219.42.195.in-addr.arpa. IN NS ns2.wineasy.se.

Primär DNS för 219.42.219.in-addr.arpa är alltså ns.wineasy.se och sekundär är
ns2.wineasy.se.

PXS (där min burk står) har adresserna 195.42.219.65 till 195.42.219.126 (64 är
nätet och 127 är broadcast). Först måste man döpa domänen till något. I Wineasys
fall kör de med nät-netmask.219.42.in-addr.arpa vilket i detta fall blir
64-26.219.42.195.in-addr.arpa. Tittar man på det ser man att det blir en
underdomän till 219.42.195.in-addr.arpa. Sedan lägger de in följande i sin
zonfil:

64-26.219.42.195.in-addr.arpa. IN SOA wormhole.pxs.se. hostmaster.pxs.se.
64-26.219.42.195.in-addr.arpa. IN NS stargate.pxs.se.
64-26.219.42.195.in-addr.arpa. IN NS ns.wineasy.se.
64-26.219.42.195.in-addr.arpa. IN NS wormhole.pxs.se.

Primär DNS för 64-26.219.42.219.in-addr.arpa är alltså wormhole.pxs.se, och de
andra två är sekundärer.

En klient som vill reverse-lookupa (eller vad fan verbet blir) ett IP-nummer
skickar ju sin förfrågan efter om.vänt.ip.nummer.in-addr.arpa vilket för
195.42.219.125 blir 125.219.42.195.in-addr.arpa. Eftersom NS för domänen
219.42.195.in-addr.arpa är ns.wineasy.se och ns2.wineasy.se kommer ju klienten
(eller snarare dennes DNS) att fråga dessa två servrar efter ovanstående
adress. Alltså måste Wineasy lägga in följande i zonfilen för
219.42.219.in-addr.arpa:

65.219.42.219.in-addr.arpa. IN CNAME 65.64-26.219.42.219.in-addr.arpa.
66.219.42.219.in-addr.arpa. IN CNAME 66.64-26.219.42.219.in-addr.arpa.
67.219.42.219.in-addr.arpa. IN CNAME 67.64-26.219.42.219.in-addr.arpa.
[...]
124.219.42.219.in-addr.arpa. IN CNAME 124.64-26.219.42.219.in-addr.arpa.
125.219.42.219.in-addr.arpa. IN CNAME 125.64-26.219.42.219.in-addr.arpa.
126.219.42.219.in-addr.arpa. IN CNAME 126.64-26.219.42.219.in-addr.arpa.

Då kommer klienten/DNS-servern som frågar att fråga efter NS för
64-26.219.42.219.in-addr.arpa för att kunna fråga efter den nya adressen den
fick via CNAME. Då får den svaret:

64-26.219.42.195.in-addr.arpa. IN NS stargate.pxs.se.
64-26.219.42.195.in-addr.arpa. IN NS ns.wineasy.se.
64-26.219.42.195.in-addr.arpa. IN NS wormhole.pxs.se.

… och följaktligen kan sedan fråga någon av ovanstående servrar efter den nya
adressen. I zonfilen för 64-26.219.42.219.in-addr.arpa (som ju wormhole
“bestämmer” över) kan sedan PXS skriva in vad de vill. Det behöver inte ens
stämma överens med A-records som pekar på det IP-numret, även om vissa
programvaror (t ex IRC-servrar) kollar att A-records och PTR-records
(reverse) stämmer överens.

PXS (eller snarare jag) har sedan i sin zonfil (den för
64-26.219.42.219.in-addr.arpa) lagt in följande NS-pekare och CNAME’s för alla
IP-nummer som ligger på min burk:

pal.64-26.219.42.195.in-addr.arpa. SOA nic.pal.pp.se. hostmaster.pal.pp.se.
pal.64-26.219.42.195.in-addr.arpa. IN NS nic.pal.pp.se.
118.64-26.219.42.195.in-addr.arpa. IN CNAME 118.pal.64-26.219.42.195.in-addr.arpa.
119.64-26.219.42.195.in-addr.arpa. IN CNAME 119.pal.64-26.219.42.195.in-addr.arpa.
120.64-26.219.42.195.in-addr.arpa. IN CNAME 120.pal.64-26.219.42.195.in-addr.arpa.
121.64-26.219.42.195.in-addr.arpa. IN CNAME 121.pal.64-26.219.42.195.in-addr.arpa.
122.64-26.219.42.195.in-addr.arpa. IN CNAME 122.pal.64-26.219.42.195.in-addr.arpa.
123.64-26.219.42.195.in-addr.arpa. IN CNAME 123.pal.64-26.219.42.195.in-addr.arpa.
124.64-26.219.42.195.in-addr.arpa. IN CNAME 124.pal.64-26.219.42.195.in-addr.arpa.
125.64-26.219.42.195.in-addr.arpa. IN CNAME 125.pal.64-26.219.42.195.in-addr.arpa.

Alltså kommer klienten/DNS-servern som frågar ännu en gång kolla upp NS för
adressen den får från CNAME, och då få svaret nic.pal.pp.se, varefter den kommer
att fråga nic.pal.pp.se efter PTR-pekaren.

Så kan man i teorin hålla på i evighet, men varje DNS-uppslagning tar ju lite
tid, så fler än två steg är nog inte tillrådligt. Redan med min config så orkar
en del otåliga applikationer inte vänta på svaret, utan kör med IP-numret direkt
istället.

I alla ovanstående exempel har jag använt hela namnet inklusive domän och
in-addr.arpa och hela köret, och sedan avslutat med en extra punkt. De flesta
DNS-servrar lägger till domännamnet som zonfilen är för automagiskt om man
struntar i punkten. Således kunde t ex:

125.64-26.219.42.195.in-addr.arpa. IN CNAME 125.pal.64-26.219.42.195.in-addr.arpa.

..i zonfilen för 64-26.219.42.195.in-addr.arpa lika gärna ha skrivits:

125 IN CNAME 125.pal

..istället. Detta gäller alla sorters records. Jag har dock använt hela namnet i
alla exempel för att göra det lättare att se alla samband.

Ett exempel på en PTR-uppslagning efter 195.42.219.125:

Till någon rootserver (eller iaf någon server högre upp i hierarkien som har
hand om 195.in-addr.arpa (ns.ripe.net) eller liknande):
Fråga: NS för 219.42.195.in-addr.arpa.
Svar: ns.wineasy.se. (och ett par andra). I svaret får man även IP-numret till
NS-servrarna, varför man slipper slå upp dessa också.

Till ns.wineasy.se:
Fråga: PTR för 125.219.42.195.in-addr.arpa.
Svar: CNAME: 125.64-26.219.42.195.in-addr.arpa.

Till ns.wineasy.se:
Fråga: NS för 64-26.219.42.195.in-addr.arpa.
Svar: wormhole.pxs.se. (och ett par andra)

Till wormhole.pxs.se:
Fråga: PTR för 125.64-26.219.42.195.in-addr.arpa.
Svar: CNAME: 125.pal.64-26.219.42.195.in-addr.arpa.

Till wormhole.pxs.se:
Fråga: NS för pal.64-26.219.42.195.in-addr.arpa.
Svar: nic.pal.pp.se.

Till nic.pal.pp.se:
Fråga: PTR för 125.pal.64-26.219.42.195.in-addr.arpa.
Svar: wield.the.scythe.of.the.soulreaper.net.

Det är inte klienten som frågar det ovan (om jag har fattat allt rätt) utan
DNS-servrarna som frågar varandra i en kedja tills de hittar rätt svar. Svaret
till klienten ser alltså ut såhär:

125.219.42.195.in-addr.arpa. IN CNAME 125.64-26.219.42.195.in-addr.arpa.
125.64-26.219.42.195.in-addr.arpa. IN CNAME 125.pal.64-26.219.42.195.in-addr.arpa.
125.pal.64-26.219.42.195.in-addr.arpa. IN PTR wield.the.scythe.of.the.soulreaper.net.

/P

[Så här skrev en person en vacker dag på en mailinglista där jag är medlem:]

> Var hittar jag en bra, gärna svensk beskrivning av IP-nummer (typ IP för
> dummies) För det är inte alltid lätt att förklara för en som inte har någon
> kunskap alls, ofta har de svårt att greppa “de fria serierna” 192.168… etc
>
> Kanske någon här rent av som kan komma med en bra förklaring. Där de olika
> klasserna förklaras.. etc
>
> The Pal hade ju en utmärkt beskrvning av en hub/switch, kanske ytterligare
> en bra beskrivning i bakfickan ?

[Så här svarade jag (The Pal), efter en lång sömnlös natt:]

Sent ska syndaren vakna. Hittade det här i mina postpones.

“Beskriv IP-nummer!” Jo tack. Beskriv livet? Beskriv Universum? Jag kunde ju
iofs kunna skriva “IP-nummer är lite pryttlar man har hittat på för att folk ska
kunna ställa dumma frågor till stackars överarbetade IT-konsulter på allsköns
skumma mailinglistor”, men det gör jag inte…

Nåväl… sömn är ju ändå överskattat, och jag kan ju inte missa chansen att
bräcka min egen hub/switch-förklaring.

Jag utgår från min egen far när jag skriver nedanstående, så bli inte förvånade
om ni känner det som om jag pratar med er som om ni vore femåringar.

En IP-adress består av två delar. Ungefär som gatuadress. Om jag ska berätta var
jag bor så säger jag inte bara “12″ utan “Mössebergsvägen 12″ trots att “12″
rent krasst också vore rätt svar. Anledningen är att det finns flera “12″, och
den jag pratar med skulle få svårt att hitta till rätt “12″ om jag inte
samtidigt sade “Mössebergsvägen”. Min adress består iofs även av stad, land och
en massa andra parametrar, men i IP-världen finns bara “gata” (som då också
består av siffror) och “nummer”.

En lång gata kan ju ha både tre och fyra siffror i gatunumret, men eftersom en
IP-adress till skillnad från en gatuadress alltid består av lika många tecken,
så är ju “nummer-delen” av adressen begränsad i storlek. Det har man löst genom
att helt enkelt flytta gränsen mellan “gatu-delen” och “nummer-delen” i
adressen, så att man tar lite siffror från “gatans” utrymme och ger till
“numret”. Från början gjordes detta genom att dela in IP-adresserna i olika
klasser efter hur många “nummer” det fick plats på “gatan”. Ju fler “nummer” man
får plats med, desto färre “gator” kan det ju finnas, eftersom det totala
utrymmet är konstant. IP-adresser är egentligen binära (liksom allt i datorernas
värld) men p g a vissa begränsningar i den mänskliga hjärnan så konverterar vi
vanligtvis adresserna till decimalt enligt en standard som kallas “dotted
decimal”. En IP-adress är 32 bitar lång, så man har delat in den i 4 lika stora
delar och satt punkter mellan delarna. Efter det har man räknat om varje del
till det decimala systemet. 32 delat i 4 ger 8 binära siffror per del. 8 binära
siffror kan bilda som mest 256 kombinationer. Därför kan en siffra i en
IP-adress skriven enligt dotted decimal aldrig vara högre än 255 (eftersom 0
också är en siffra kan den aldrig vara 256). Låt mig ge några exempel:

Den binära "riktiga adressen": 11000000010001111101110000001010
Och så sätter vi dit punkterna: 11000000.01000111.11011100.00001010
Och så räknar vi om varje del för sig till decimalt: 192.71.220.10

Då har vi en adress som iaf är liiite lättare att komma ihåg för en människa.

För att tillmötesgå olika behov i olika nätverk hittade man på klasser. Adresser
som börjar med en nolla är klass A, adresser som börjar på en etta och en nolla
är klass B och adresser som börjar två ettor och en nolla är klass C osv.
Alltså:

00XXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX: Klass A
10XXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX: Klass B
110XXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX: Klass C
1110XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX: Klass D
11110XXX.XXXXXXXX.XXXXXXXX.XXXXXXXX: Klass E

Som synes är det bara den första oktetten som avgör klasstillhörigheten. Räknar
vi om den första oktetten till decimalt får vi att IP-nummer som börjar med:

0-127 är klass A
128-191 är klass B
192-223 är klass C
224-239 är klass D
240-243 är klass E (Här är jag osäker på om det gäller 240 och uppåt, eller om
det finns en övre gräns på 243… Swmike eller nån kanske?)

Klass A-C är vanliga klasser. Klass D är reserverad för multicast och klass E
för experimentellt bruk.

Tjafset om gata och nummer då? Jo, från början så bestämdes att var gränsen
mellan “gatu-delen” och “nummer-delen” skulle vara bestäms av
klasstillhörigheten (ungefär som i dagens Jordbro .

I adresser i klass A (de som börjar på 0-127) så sattes den vid den första
punkten. Alltså var den första siffran vilken “gata” adressen låg på. Räknar man
lite snabbt så ger det 128 möjliga “gator”. Resten av siffrorna efter den första
punkten fick bli “numret”. Det ger med lite snabb huvudräkning(!)
256*256*256=16777216 möjliga “nummer” per “gata”. Mao rätt få “gator”, men en
väldig massa “nummer” på varje “gata”. Översatt till IT alltså rätt få nätverk
men en väldig massa datorer i varje nätverk.

Alla företag har ju inte så stora nätverk, men alla företag har heller inte
IP-adresser i klass A. Då skulle dessutom inte nätverken räcka tlll eftersom det
finns något fler företag än 128 här i världen.

I adresser i klass B (128-191) sattes gränsen på den mittersta punkten. Det ger
(återigen med min snabba huvudräkning) 64*256 “gator” (inte 63*256, eftersom både
128 och 191 teoretiskt sett är möjliga) möjliga “gator” med 256*256=65536 möjliga
“nummer” per “gata”.

I klass C sattes den vid den sista punkten, vilket ger 32*256*256 möjliga nätverk
med 256 möjliga datorer i varje.

D är multicast. Multicast är sändningar som går till flera adresser som
inte nödvändigtvis ligger i samma nätverk.

E är för experimentellt bruk. Experimentellt bruk är experimentellt bruk.

Jag kommer inte att nämna klass D eller E i fortsättningen. Multicast läggar jag
ut på entreprenad till Anders@Kamera. Det experimentella får min namne Magnus ta
hand om. Varsågod och bräcka mig, Pojkar!

För att krångla till det hela så bestämde man att det lägsta “numret” på varje
“gata” fick representera själva “gatan”. Alltså kan inte en dator t ex ha
IP-numret 192.168.100.0, eftersom det står för hela nätverket
192.168.100.0-192.168.100.255. Dessutom bestämdes att alla nätverk ska ha en
“broadcast-adress”. Skickas nåt till denna adress så lyssnar alla datorer i hela
nätverket. Ungefär som när glassbilen kommer tutande på “gatan”. Som
broadcast-adress valdes det högsta IP-numret i varje nätverk. För
192.168.100.0-nätet alltså 192.168.100.255. Då har vi minskat antalet möjliga
datorer på det nätverket från 256 till 254. (För att ytterligare krångla till
det hela finns det nätverk som kör med det högsta numret som nät-adress och det
lägsta numret som broadcast, men det är så sällsynt så det kan vi bortse ifrån.)

Så… hänger ni med? Nähä… nåväl, jag fortsätter iaf…

Men.. om vi har ett företag som har 10000 datorer i nätverket då? Ska vi slösa
bort en klass B med 65534 möjliga datorer på dem? Då kastar vi ju bort 55534
adresser till ingen nytta, och antalet adresser är ju faktiskt begränsat.
Samtidigt känns det ju jobbigt att administrera ihop 40 stycken klass C-nät. Det
måste väl gå att lösa?

Visst. Enkelt. Vi flyttar gränsen för “gatu-delen” och “nummer-delen” så den
ligger mitt emellan klass B och klass C. I princip så skrotar vi alltså
klassindelningen, eftersom det ju inte går att ha olika klasser för alla olika
storlekar på nätverk, och definitivt inte med samma kriterium (antalet ettor i
början) som förut. Vi inför nåt som heter subnetmask istället. Vad är då det?
Jo, det är ett binärt tal som är lika långt som IP-numret. Den talar om för oss
vad som är en del av “gatan” och vad som är en del av “numret”. Alltså en “mask”
som vi lägger över IP-adressen, som döljer “numret” när vi bara vill veta
“gatan” och som tvärtom när vi vill veta tvärtom. Alltså:

IP: 11000000010001111101110000001010
Och så lägger vi på en netmask, först samma netmask som standard enligt den
gamla klassindelningen:
Netmask: 11111111111111110000000000000000

Huh? Vaddå ettettettettnollnollnollnoll osv osv?? Vad betyder det här nurå? Jo,
ettorna talar om att alla siffror i IP-adressen vars plats i netmasken hålls av
en etta ingår i “gatu-delen”. De som motsvarar en nolla ingår i “nummer-delen”.
Ovanstående netmask betyder alltså att “gatan” heter 1100000001000111 och
datorn har i sin tur “nummer” 1011100000001010. Om vi sätter IP-numret och
netmasken under varandra syns det ännu bättre (slå på courier eller nån annan
fixed-width-font):

IP-nummer:      11000000.01000111.10111000.00001010
Netmask:        11111111.11111111.00000000.00000000
Nätverk/"gata": 11000000.01000111
Dator/"nummer":                   10111000.00001010

Även netmasken skrivs om till dotted decimal, och i ovanstående exempel gör vi
det lätt för oss, eftersom gränsen går precis på en punkt. Decimalt:

IP-nummer: 192.71 .220.10
Netmask:   255.255.0  .0
Nätverk:   192.71
Dator:             220.10

Enkelt. Där det står 255 är det nätverks-delen och där det står 0 är det
dator-delen. Men om vi vill ha 10000 datorer i ett nätverk och snåla med
adresserna, så blir det inte lika enkelt:

För att få ihop minst 10000 unika kombinationer behöver vi 14 binära siffror
(dec 10000 = bin 10011100010000). Alltså måste vi flytta gränsen till 14 siffror
från slutet, vilket ger netmask 11111111111111111100000000000000. Skriver vi om
det decimalt blir det 255.255.192.0. Exempel:

IP-nummer bin: 11000000.01000111.10111000.00001010
Netmask bin:   11111111.11111111.11000000.00000000
IP-nummer dec: 192     .71      .220     .10
Netmask dec:   255     .255     .192     .0
Nätverk bin:   11000000.01000111.10
Dator bin:                         111000.00001010
Nätverk dec:   192     .71      .Ehh?
Dator dec:                       Ehh?    .10

Helt plötsligt stämmer det ju inte. Tredje siffran decimalt är ju varken 255
eller 0. Hur ska vi då kunna veta om vi ska räkna den till nätverket eller
datorn? Svaret är både och. Vi får ta och räkna lite till bara (en himla massa
räknande blir det). Eftersom vi har utöket antalet möjliga nätverk (med två
binära siffror) så blir det ju flera möjliga nätverk som börjar på 192.71, och
inte bara ett som i klass-samhället. dessa kommer (*räkna lite binärt*) att
vara:

192.71.0.0 – 192.71.63.255
Nät: 192.71.0.0, broadcast: 192.71.63,255 och datorerna allting mellan (och
inklusive) 192.71.0.1 och 192.71.63.254

192.71.64.0 – 192.71.127.255
Nät: 192.71.64.0, broadcast: 192.71.71,255 och datorerna mellan 192.71.64.1 och
192.71.71.254

192.71.128.0 – 192.71.191.255
Nät: 192.71.128.0, broadcast: 192.71.191,255 och datorerna mellan 192.71.128.1
och 192.71.191.254

192.71.192.0 – 192.71.255.255
Nät: 192.71.192.0, broadcast: 192.71.255,255 och datorerna mellan 192.71.192.1
och 192.71.255.254

Vi får alltså plats med 4 stycken företag med 16382 datorer på varje, och det
inom samma adressutrymme som vi bara hade fått plats med ett företag i om vi
hade följt den gamla klassindelningen.

Är det jobbigt? Bra. Då flyttar vi netmasken två steg till, så vi har 20 binära
siffror som nätverksdel och 12 som datordel:

IP-nummer bin: 11000000.01000111.10111000.00001010
Netmask bin:   11111111.11111111.11100000.00000000
IP-nummer dec: 192     .71      .220     .10
Netmask dec:   255     .255     .240     .0
Nätverk bin:   11000000.01000111.1011
Dator bin:                           1000.00001010
Nätverk dec:   192     .71      .?
Dator dec:                       ?       .10

Näten blir:

192.71.0.0 – 192.71.15.255
192.71.16.0 – 192.71.31.255
192.71.32.0 – 192.71.47.255
192.71.48.0 – 192.71.63.255
192.71.64.0 – 192.71.79.255
192.71.80.0 – 192.71.95.255
192.71.96.0 – 192.71.111.255
192.71.112.0 – 192.71.127.255
192.71.128.0 – 192.71.143.255
192.71.144.0 – 192.71.159.255
192.71.160.0 – 192.71.175.255
192.71.176.0 – 192.71.191.255
192.71.192.0 – 192.71.207.255
192.71.208.0 – 192.71.223.255
192.71.224.0 – 192.71.239.255
192.71.240.0 – 192.71.255.255

Urk… jag brukar komma ihåg såna häringa nummer utantill, men ovan fick jag
tänka till ordentligt för att få alla näten rätt.

Som vanligt är det lägsta numret i varje nätverk själva nätet (används t ex vid
routing) och det högsta är broadcast.

Nu fick vi ihop 16 nätverk med 4094 möjliga datorer på varje. Bättre än att
slösa bårt 16 hela klass B-nät eller bråka med att dela ut 256 klass C-nät (16
stycken per företag). Lägg märke till att antalet B-nät blev detsamma som
antalet C-nät per företag i nyss skrivna mening? Kan det ha med att göra att vi
bröt den tredje oktetten precis mitt itu kanske? Kanske t o m att antalet
möjliga kombinationer man kan få ihop med 4 binära siffror (en oktett delad mitt
itu) är just 16? Ahh… jag älskar när logiken går ihop!

På fackspråk kallas ovanstående för “classless”, eftersom man skiter i de gamla
klassindelningarna. Även om man kör classless så är adresserna ovanför 224.0.0.0
fortfarande reserverade för multicast och experiment/framtida
användningsområden.

Ovanstående “isärbrytning” av en oktett behöver naturligtvis inte ske just i den
tredje oktetten, utan kan lika väl vara i den första, andra eller fjärde. Då
flyttar man bara mina räkneexempel till de oktetterna, och sätter 255 eller 0 i
de andra. Rent teoretiskt går det faktiskt att ha netmaskar där ettorna och
nollorna inte är sammanhängande, men för en människa är det lite väl. Dessutom
ser jag inte någon större anledning, mer än just “because you can”. De flesta
utrustningar skriker om man försöker.

“Privatnäten” då? De “fria serierna”? Vad är det för larv?

Om man ska ge varje dator på hela jorden en egen IP-adress räcker de helt enkelt
inte till. Dessutom skulle det bli alldeles för stort att administrera. Varje
dator behöver ju faktiskt inte vara (och bör inte vara) åtkomlig från varje tänkbar
avsändare på hela Internet. Vi kan ju t ex börja med att plocka bort alla
klienter på nätverket, och dessutom alla servrar med enbart interna göromål.
Sagt och gjort. Vi ställer dit en firewall som skyddar alla dessa. Firewallen
tar emot alla begärningar (heter det så?) från datorerna innanför, och
vidarebefordrar sedan dessa ut på Internet. Då räcker det med att datorerna ute
på Internet vet vad firewallen har för adress för att skicka ett svar.
Firewallen håller reda på vilken dator som frågar vad, och skickar sedan svaret
till rätt frågeställare (tekniken kallas NAT eller PAT, två olika tekniker för
att göra samma sak på två olika sätt).

Bra. Då kan vi ju sätta vilka IP-adresser vi vill på insidan. Eller? Nej, det
kan vi inte. Låt oss t ex på skoj använda serien 192.71.0.0 till alla interna
datorer. 192.71.220.10 som jag använt ovan är egentligen IP-adressen för Tele2′s
huvud-DNS-server nic.swip.net. Säg att en intern dator också har 192.71.220.10.
Det gör väl ingenting? Datorerna ute på Internet ser ju ändå inte den? Nej, men
datorern i det interna nätverket gör. Så fort en intern dator vill fråga
nic.swip.net om nånting så kommer den att fråga den interna datorn med
192.71.220.10 istället, och får då naturligtvis inget svar. Jamen, skit i
nic.swip.net då! Jaha… och om IP-adressen istället användes av
www.microsoft.com då? Det skulle innebära att ingen på det interna nätverket
skulle kunna surfa till www.microsoft.com, och den stackars datorn som har det
IP-numret internt skulle bli överöst med WWW-förfrågningar som den inte kan
svara på.

Hur löser vi det här nudå? Jo, vi reserverar ett gäng nät som inte får användas
ute på Internet, och alltså kan vi använda dem fritt i det interna nätet,
eftersom det aldrig kan bli några krockar. De enda som kan ha samma IP-nummer är
ju datorer på andra interna nät, som vi ändå varken kan eller ska komma åt.

De reserverade näten är:

10.0.0.0 255.0.0.0 (d v s 10.0.0.0 – 10.255.255.255)
172.16.0.0 255.255.240.0 (d v s 172.16.0.0 – 172.16.31.255)
192.168.0.0 255.255.0.0 (d v s 192.168.0.0 – 192.168.255.255)

Dessa kan man alltså använda internt utan risk för att någon dator ute på
Internet använder samma adress som en intern dator.

Dessutom är 127.0.0.0 255.0.0.0 reserverad för den egna datorn (localhost).
Pingar du en adress som börjar på 127 så pingar du alltså dig själv, oavsett
vad du skriver efter 127.

Hmm… sluttampen… känns skönt… fast det är väl ändå ingen djävul som har
orkat läsa ändå hit ner… Jag har skrivit i snart 3 timmar och 40 minuter…
måste vara det längsta brev jag skrivit alla kategorier, digitalt som analogt.
Jag CC:ar det här till min flicka (hon pluggar nätverk), och hon kommer väl att
undra varför jag inte skriver lika långa brev till henne… nåja, en senare
huvudvärk.. lite kort om routrar och DNS, sen är jag klar: (I löv jo, gumman!)

Routrar:

Routrar är datanätverkens postterminaler. De håller reda på vilka nätverk som
ligger var (eller iaf åt vilket håll). Tänk dig först en liten postterminal.
Receptionen på ett mindre företag t ex. De behöver inte bekymra sig så mycket om
vart posten ska. Antingen kommer den med brevbäraren, och då ska den till
postrummet, eller så ligger den i utkorgen, och då ska den till Posten (via nån
postlåda). Likadant fungerar en liten router (t ex ISDN-routern jag är
uppkopplad via nu). Den har ett lokalt nätverk (postrummet) och en “default
gateway” (Posten). Allting som inte ska till det lokala nätverket skickar den
till default gateway (i mitt fall dialup-server på Tele2 som tagit emot
ISDN-samtalet som min router har ringt upp). Alla routrar har en tabell över
alla nätverk de känner till samt en default gateway. Min router har en rätt
enkel tabell med bara två rader.

Rad 1: Det lokala nätverket. I mitt fall 192.168.113.0 med netmask
255.255.255.0. Allting som ska hit skriker den ut på det lokala nätverket.

Rad 2: Default gateway. I mitt fall Tele2′s dialup-server. Hit skickar den
allting som inte ska till passar in på nån rad ovan. I mitt fall allt som inte
ska till 192.168.113.0.

Ute på Internet finns det stora postterminaler. Årsta eller Tomteboda är blaha
blaha i jämförelse. De har jättetabeller med tusentals nätverk och massor med
olika linor hit och dit. Varje rad innehåller ett nätverk (Nät-adressen och
netmask) och en IP-adress dit allting till det nätet ska skickas. Uppe i toppen
finns t o m routrar utan default gateway. De kan alltså ALLA nät. Hur är nu det
möjligt? Det blir ju miljoners miljoners olika nätverk mad alla möjliga olika
netmaskar. Jo, de klumpar ihop näten. Ta t ex alla 192.71-näten ovan. Uppe bland
de här höjdarna finns inte alla de näten. Där finns bara 192.71.0.0 med netmask
255.255.0.0 och allting som ska dit skickas åt samma håll. (Längre upp finns nog
bara 192.0.0.0 255.0.0.0 dessutom.) Längre ner finns det sedan andra mindre
routrar (som fortfarande skulle skrämma slag på min lilla Shiva) som i sin tur
delar upp 192.71.* till de mindre näten jag radade upp några meter upp i det här
mailet. Till slut kommer (förhoppningsvis) alla paket fram till rätt adress. De
stora routrarna känner alltså inte till alla smånäten, utan bara “klumparna”.
Det ger avlastning åt dessa, samt frihet åt oss här nere på marken att mixtra
runt med våra smånät utan att behöva tala om det för de stora pojkarna varje
gång.

DNS:

Dotted decimal i all ära, men det är ändå lite jobbigt att komma ihåg alla
adresser i huvudet. Tänk om ni skulle få skriva IP-nummer till varje site ni
surfar till? Testa det bara en enda dag, så får ni se själva. Alltså måste vi
hitta på nåt som är enklare för en människa att komma ihåg än en hop siffror.
Bokstäver? Njaa.. Ord? Ja! Ord kommer vi ihåg. Vi är uppvuxna med ord. Vi
använder ord varje dag. Ord kan vi och ord kommer vi ihåg. Därför spikade man
ihop ett system där vi bara behöver komma ihåg orden, och så översätter datorn
det med siffror. Från början fanns en fil “hosts” med en tabell över alla ord,
och vilka IP-adresser de betydde. Den filen blev ganska stor med tiden (räkna
gärna ut hur många rader det skulle bli idag!), så det ersattes med ett system
där det står servrar lite varstans som håller reda på dessa ord och IP-nummer.
Varje server har sitt ansvarsområde, din “domän”. Det finns stora servrar som
har hand om hela toppdomäner, mellanservrar som har hand om vanliga domäner, och
i vissa fall små servrar som har hand om underdomäner. Initialt innehåller de
bara de domäner de har hand om. De största servrarna “root-servrarna” har en
lista med alla toppdomäner, och ett IP-nummer som i sin tur pekar ut vilken
server (inkl IP-nummer) som har hand om vilken toppdomän. nic.nic-se.se har t ex
hand om hela .se

nic.nic-se.se har i sin tur en lista över alla domäner.se samt vilka servrar
(inkl IP-nummer) som har hand om vilken domän. Dessa servrar i sin tur har dels
listor över alla datorer som har namn under deras respektive domän och vilka
IP-nummer de har. De kan också välja att lägga ut underdomäner på “entrepenad”
till mindre servrar, och peka ut de servrarnas namn och IP-nummer. Alla klienter
förses sedan med en eller flera DNS-servrar som de ska fråga när de vill ha reda
på vilket IP-nummer ett visst namn har. Finns namnet i deras tabell svarar det
helt enkelt. Finns inte namnet med har de i sin tur en annan större server som
de frågar. Om inte heller den vet frågar den vidare ännu högre upp. Till slut är
det någon som vet iaf vilken DNS-server som har hand om den toppdomän det
handlar om. Den frågar då den servern, som i sin tur frågar vidare neråt, och
när svaret kommer vandrar det samma väg tillbaka. Hela vägen läggs namnet och
IP-numret in i cachen på servrarna med en timeout. Om de sedan får samma fråga
igen, inann timeouten har gått ut, så kan de svara utan att behöva fråga
vidare den här gången.

/Pal Pedagog

> Ursäkta en dum fråga – vad är skillnaden mellan en
> switchar och hubbar och fördelar med respektive?

En hub har ett gäng portar. Om nånting kommer in på en port skriker den ut samma
sak på alla portar. Den kan bara skrika en sak i taget.

En switch har ett gäng portar. Om nånting kommer in på en port lyssnar den efter
vem som sa nåt, sen antecknar den att denna någon sitter på porten ifråga. Sen
kollar den till vem det sagda ska. Om adressaten finns med i switchens
anteckningar skriker den bara ut det på just den port som finns antecknad för
just den adressaten. Om adressaten inte finns med i anteckningarna skriker den
ut det på alla portar. Förhoppningsvis svarar adressaten nånting, och då får ju
switchen ett alldeles utmärkt tillfälle att anteckna vilken port svaret kom på.
Efter ett tag har switchen massor med anteckningar som ger en rätt bra bild på
vem som sitter på vilken port, vilket gör att tillfällena när den måste skrika
på alla portar blir färre och färre. Eftersom en del dumma
nätverksadministratörer flyttar på burkar så de hamnar på andra portar, eller
lägger till nya burkar, eller tar bort burkar, eller gör andra sådana där dumma
saker som bara nätverksadminstratörer kan hitta på, så har switchen en timeout.
Har den inte hört något från en viss burk på ett tag stryks den ur
anteckningarna. På så viss hålls anteckningarna uppdaterade, och nätverket
utnyttjas mycket effektivare, eftersom switchen kan skicka flera meddelanden
samtidigt så länge inget ska till / kommer ifrån samma port. En 10 mbit/s switch
kan alltså vara effektivare än en 100 mbit/s hub över en viss mängd portar och
trafik.

/P