basis vereisten om te kunnen werken op
het netwerk.
1.1ethernet interface
Gemaakte veranderingen dienen te
gebeuren in de configuratie files. Anders zijn deze slechts tijdelijk tot de
volgende reboot, want dan worden deze originele configuratie files terug
opnieuw ingelezen.
Het is mogelijk om via het commando ifconfig de interfaces configuratie aan te
passen (tijdelijk).
/sbin/ifconfig eth0 192.168.1.17
/sbin/route add default gw 192.168.1.1
ip address show
ip address add 192.168.1.17/24 brd + dev eth0
ip address del 192.168.1.17 dev eth0
ip -s link show interface-name ip -s link show eth0 ip -s link show ppp0
·lo : loopback interface, used to access local
services such as proxy or webserver http://127.0.0.1/
·eth0 : the first Ethernet interface connected to
network switch or router
·ra0 : the first wireless interface
·ppp0 :the first point-to-point interface, used to
connect via VPN or dial up service
De interfaces configuratie file is terug te vinden /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
auto lo
iface lo inet loopback
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.17
netmask 255.255.255.0 gateway 192.168.1.1
network 192.168.1.0
# dns-* options are implemented by the # resolvconf package, if installed dns-domain example.com dns-nameservers 192.168.1.1
Om deze verandering actief te maken,
dient natuurlijk desbetreffende daemon te worden herstart
/etc/init.d/ networking restart of
service
networking restart
ifconfig ageeft
al de interfaces en hun status weer
route ngeeft
de routes als ook de gateways weer
netstat nrof via het commando
route -n
Kernel IP routing table
DestinationGatewayGenmaskFlags Metric Ref Use Iface
127.0.0.0*255.0.0.0U002 lo
192.168.1.0*255.255.255.0 U00137 eth0
default192.168.1.10.0.0.0UG1036 eth0
voor subinterface van een interface
dient gewoon hetzelfde te gebeuren als bij een andere netwerk interface
PREROUTING chain De pakket wijzigingen gebeuren vóór het routeren. Packet translation gebeurt onmiddellijk bij
het binnenkomen op het systeem; het destination (bestemming) ip adres van
de pakketten wordt aangepast naar een overeenstemmend ip-adres, route van
de server - DNAT (destination
NAT).
POSTROUTING chain De packet wijzigingen gebeuren na het routeren. Packet translation gebeurt voor het verlaten
van het systeem; het source (bron) ip-adres van de pakketten wordt aangepast
naar een overeenstemmend ip-adres. - SNAT
(source NAT).
OUTPUT chain NAT voor uitgaande pakketten van de firewall, lokaal gegeneerde
pakketten
Een SOA record, START OF AUTHORITY, bevat technische informatie over de betreffende
domein, DNS-server,
·Class -
IN
toont het type van record; IN staat
voor Internet of Intranet.
·TTL
604800
De TTL bepaald de duur in secondes dat de record mag worden gecached door de
client. Indien deze op 0 geset is, duidt erop dat het niet dient gecached te
worden. $TTL als de zone default TTL
·nameserver
De naam van de master server pie.lan.zone domain naam
·email
Het e-mailadres van de beheerder, met de apenstaart vervangen door een punt
admin.pie.lan.e-mail
adresadmin@pie.lan.
·serial
Dit is het serienummer van de zonefile. Wanneer het serienummer verhoogd wordt,
zal de master de zonefile opnieuw inlezen na een reload, en de slaves zullen
een zonetransfer doen.
·refresh
Dit is het tijdsinterval waarin een slave DNS-server bij de master controleert
of het serienummer verhoogd is.
·retry
Als de masterserver onbereikbaar was bij de laatste controle van het
serienummer, dan gaat de slave opnieuw proberen na dit tijdsinterval
·expire
Als de masterserver zo lang down is geweest als aangegeven in expire, dan verwijdert de
slave de gecached zone informatie.
·minimum
Negative caching
Wanneer er een ondervraging gebeurt naar een niet bestaand subdomain,
resulteert dit in een NAME ERROR = NXDOMAIN, en zal dit bepalen hoe lang dit
moet gecached worden door de ondervrager.RR resource record RFC 2308 (in BIND 9) wordt de
$TTL als default TTL gebruikt voor de niet bestaand subdomain response die door
de ondervrager wordt gecached. Bepaald het aantal secondes een domain name lokaal wordt
gecached , voordat deze vervalt en terug opnieuw door een authoritative
nameserver geupdate moet worden, of terug opnieuw een ondervraging toestaat.
CNAME records, Canonical name, worden vaak bij
dynamische IP's gebruikt. Als het IP van de server verandert, dan moet er
slechts één record worden gewijzigd, nl het A-record.
Wordt vooral bij virtuele hosts op een server gebruikt, bvb hostingsfirmas.
Maakt het mogelijk om onder verschillende benamingen bereikbaar te zijn.
Een
PTR record, POINTER,zet een IP adres om in een naam.
Mail servers controleren (soms) of de afzender van een mailbericht een echte
server is en niet een thuis-computer is, dat door een virus besmet is. Door de
aanwezigheid van een PTR record kan de ontvangende server weten of de zender
wel een mailserver is: 10.1.168.192.in-addr.arpaINPTRmail.pie.lan 10.in-addr.arpaINPTRwww.pie.lan Het IP adres wordt eerst omgezet in een naam (het DNS systeem werkt
enkel met namen als keys).
Een
MX record, MAIL EXCHANGER,is een record om aan te geven welke
mailservers in welk domein draait.
pie.lanINMX10
mail.pie.lan pie.lanINMX17 mx.pie.lan Als er meerdere mail servers zijn, krijgt
elke mailserver een verschillend voorkeursnummer.
De voorkeursnummer bepaalt de prioriteit van de
mail-server, hoe lager het nummer hoe hoger de prioriteit.
Er dient voor elke mail-server een A record aangemaakt te worden die mail.pie.lan en
mx.pie.lan
omzet in een IP adres.
Een CNAME is niet toegestaan, want een MX record is in feite al een soort
CNAME.
Innamed.conf.optionsworden oa de
forwarder gegevens meegegeven.
«DHCP-server» De configuraties voor DHCP met de juiste
DNS gegevens moeten ook aangepast worden file/etc/dhcp/dhcpd.confen natuurlijk de service herstarten
#option domain-name-servers 192.168.1.1;
option domain-name-servers 192.168.1.10;
Om deze verandering actief te maken, dient natuurlijk
desbetreffende daemon te worden herstart
hier worden twee verwijzingen in aangebracht, nl voor de zones (A ; van
naam naar IP) en voor reverse zones (PRT; van IP naar naam) /etc/bind/named.conf.default-zones
zone
"pie.lan" {
type master;
file
"/etc/bind/master/master.pie.lan";
};
zone
"1.168.192.in-addr.arpa" {
type master;
file
"/etc/bind/master/192.168.1.rev";
};
In named.conf.default-zonesworden gegevens van de verschillende zone(s)
meegegeven.
Nu dient de DNS configuratie file ook worden aangepast namelijk naar
zijn eigen ip-adres ofloopback adres,
daar de DNS-service van de router niet meer gebruikt wordt. /etc/resolv.conf
De configuraties voor DHCP bevinden zich in de
configuratie file /etc/dhcp/dhcpd.conf De DHCP-server
(master of alleen) dientauthoritativete zijn, zodat
de client verplicht wordt de gegevens
bekomen door deze server te gebruiken.
De tijd is zeer belangrijk bij DHCP, zeker wanneer er meerdere DHCP-servers
zijn geconfigureerd ivm de timestamps.
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
Imagine you are sitting in front of a machine named "home" that has a keyboard, mouse, display, and is running
an X server. Now you open a terminal and ssh to a machine called "remote" (which doesn't need to have an X server running), and
run a program like "firefox" which pops a window in your screen. How
does this all work? First, let's clear up the
client/server terminology confusion. When talking about X:
·X client: a
process (like firefox or xemacs) which uses the X client API to display things
and receive mouse/keyboard events.
·X server: a
process (usually just "X") which X clients connect to. At times (as
we'll see below) other processes can act as X servers.
Whenever
an X client starts up, it reads the local $DISPLAYenvironment variable, whose value looks like: [hostname]:display_number[.screen_number]. The X client immediately opens a connection to that X server.
If it can't, it fails:
user@home: echo $DISPLAY
:0 # hostname
is "localhost" by default
user@home: xcalc # pops up a
calculator on my screen
user@home:
DISPLAY="nosuchhost:99"
user@home: xcalc Error: Can't open display:
nosuchhost:99
Now let's see what happens when you
ssh to another machine:
user@home: ps aux | grep
X # yep,
X server running @home root ... /usr/bin/X :0 ...
user@remote: ps aux |
grep X #
nope, no X server here
user@remote: echo
$DISPLAY :11.0
user@remote: xcalc # pops up
screen @home
Wait a minute, the $DISPLAYvariable is pointing to the
localhost ("remote"). Natural questions to ask at this point:
·There
is no X server @remote,
so why didn'txcalcjust fail on startup?
·Why
was the display number "11".
·How
did xcalcshow something @home?
The
answer has to do with the ssh-daemon running @remote:
user@remote: ps aux |
grep user root ... sshd:user@pts/11
What's happening is that there's an
"X emulator" running@remote that was setup just for your ssh session, that is listening
on display 11. To review, here's a play-by-play:
1.You
type "ssh -X user@remote" in your terminal
2.The
ssh process connects to the sshd server @remote.
3.sshd spawns a new process that is an X-server-emulator listening
on some display number, e.g. "11"
4.sshd sets the $DISPLAYto point to that local "X-server" (e.g.
":11")
5.xcalc reads this$DISPLAY and conncects to this X-server. xcalc thinks it's displaying to the local machine.
6.the
X-server-emulator simply forwards the X commands from xcalc through the ssh connection, to the original ssh process.
7.The
ssh process @homenow acts as a normal X-client and
sends those commands to the X-server@home.
Some of you might be wondering:
wasn't the X protocol designed to go over the network? Can't you do all this
without ssh? You might be tempted to try something like:
user@remote:
DISPLAY="home:0" user@remote: xcalc
This
doesn't work because the X server@homewon't let other hosts connect to it. To change this (not
that you should -- see below) you can do:
user@home: xhost +remote
xhost is a command which says
"that host can connect to our X-server". However, everybody uses ssh
X forwarding instead. Here are some security reasons
why:
·normally,
X-traffic (like your keystrokes) is sent unencrypted from X-client to X-server.
·ssh
nicely sends that data through an encrypted channel, so it doesn't go over the
internet in the clear.
·"xhost +remote"
is putting a lot of trust in 'remote' being a nice guy. If remote ever gets
hacked, it could connect to the X-server @homeand listen to all
its keystrokes.
There's also an issue with firewalls: by doing "DISPLAY=home:0", you're assuming that a
connection can be established from remote -> home. But
this isn't always possible -- homemight
be sitting behind a firewall (like your Netgear router). Since the
ssh-connection was setup from home-> remote,
it takes advantage of this already-established connection. Other notes for
the curious:
·if
$DISPLAYis set to "localhost:0" (or any explicitly named
host) it uses tcp-ip to send the X-traffic locally.
·if$DISPLAYis
just ":0" it uses a special (more
efficient, non-tcp-ip) connection.
2.Settings on debian
/etc/ssh/sshd_config
: X11Forwardingis set to yes
·UNIX
enable X11 forwarding op de server, dan is op zijn minst het xauth programma vereist.
1.installeer xbase-clients op de server (of de package dat xauth bevat)
2.problemen wanneer je verandert van
user
X authenticatie is gebaseerd op cookies, voor de server vandaar deze toevoeging
root@debian:/home# xauth list
root@debian:/home# xauth list
$DISPLAY
debian/unix:0mit-magic-cookie-14b73137421627917931dbc5b67ccab8c
Officially the "X Window System," but also called
"X Windows," "X11" or simply "X," it is an open
source windowing system developed at MIT in the early 1980s. It was created to
provide a common graphics rendering engine for Unix applications. Prior to X, CAD
and scientific modeling applications that required graphics output used
proprietary software to render images. X is also the de facto graphics engine
in Linux desktops.
Version X11 was released in 1987 and remains the current standard, having
undergone many revisions. The X.Org Foundation (www.x.org) governs the X Window
standards for Unix/Linux desktops, which evolved from XFree86 implementations
(www.xfree86.org). Hummingbird's Exceed (www.hummingbird.com) and
AttachmateWRQ's Reflection (www.wrq.com) are commercial X Window
implementations for Windows desktops.
1.1.Network Transparency One of the unique
features of X is that it allows applications to run on a network server, but be
displayed on a desktop machine. This was very significant in the 1980s and
1990s when servers were far more powerful than user machines. In the early days
of X, dedicated X Window hardware, known as "X terminals," were
widely used. They accepted input, rendered output and performed no application
processing.
1.2.The X Window Manager X Window, by itself,
generates borderless windows in fixed screen locations. It requires a
"window manager" to add borders and buttons and the ability for users
to resize and move the windows on screen. The Tabbed Window Manager (twm) has
been the default X window manager, but more than three dozen others have been
used, including AfterStep, Blackbox and Enlightenment. The KDE and GNOME user
interfaces for Linux use Kwin and Metacity respectively as their window
managers.
1.3.Server Runs in Client; Client Runs in Server X Window was designed as
a client/server architecture. The application is the "X client," and
the software that accepts keyboard and mouse input and renders the images on
screen is called the "X server." Communications between X clients and
the X server is via the X
