Linux: internet delen (DHCPD en NAT m.b.v. iptables)

Pagina: 1
Acties:

  • Ablaze
  • Registratie: December 2003
  • Laatst online: 02-01 13:32
Hoi, ik gebruik sinds een paar dagen Linux. Onlangs heb ik het voor elkaar gekregen om mijn Speedtouch USB modem (ppp0) succesvol te configureren. Nu wil ik echter een andere PC in mijn netwerk (op eth0) mee laten genieten van dit succes en het internet delen.

Ik dacht dit te doen met de configuratie, die onderaan deze post staat. Helaas blijkt dat de DNS adressen niet geforwarded worden, ik kan op het netwerk alleen internetten door IP nummers in te toetsen. Waarschijnlijk moet ik nog iets configureren, maar ik weet niet wat? Vandaar dat ik jullie hulp inschakel. Ik gebruik DHCPD om PC's een IP adres te laten toekennen, de gateway wordt goed overgenomen. De DNS servers in DHCPD heb ik overgenomen van /etc/resolv.conf.

Bestanden:

/etc/rc.d/rc.ipmasq (wordt aangeroepen vanuit /etc/rc.d/rc.local)
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/sh

IPTABLES=/sbin/iptables

#All The lines below are NAT routing

# flush any old rules
$IPTABLES -F -t nat
# turn on NAT (IP masquerading for outgoing packets)
$IPTABLES -A POSTROUTING -t nat -o ppp0 -j MASQUERADE

# enable IP forwarding (of incoming packets)
echo 1 > /proc/sys/net/ipv4/ip_forward


/etc/dhcpd.conf
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#These lines are for lease times and for update style.
#These do not need to be changed for normal operation

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;

# Change the subnet mask to the subnet mask of your network
# In most cases for a small network it will be 255.255.255.0

option subnet-mask 255.255.255.0;

# Change this to the IP address of the computer that is connected to the internet
# In most cases this will be the same as the computer as this script is running on

option routers 192.168.1.1;

# Change this to the IP addresses of the primary and secondary
# DNS servers of your ISP (internet service provider)

option domain-name-servers 195.121.1.34, 195.121.1.66;

# This is the range of IP address that will be given out. It’s best
# To use the 192.168.0.0 range as this is set aside for none internet networks
# This will hand out IPs address in the range of 192.168.0.10 to 192.168.0.255

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.80;
range 192.168.1.128 192.168.1.254;
}

#The NIC with this MAC address will always get the same IP address 192.168.03

host NAME_OF_HOST {
# NAME_OF_HOST should be changed to the name of that computer.
hardware ethernet 00:0C:6E:E2:77:67;
fixed-address 192.168.1.1;
}

  • PowerSp00n
  • Registratie: Februari 2002
  • Laatst online: 17-11-2025

PowerSp00n

There is no spoon

De opgegeven DNS servers zijn hiervanuit niet te pingen hoor (option domain-name-servers). Ook kun je in je dhcpd.conf de regels vanaf nummer 34 31 weg halen als je dit niet gebruikt.

[edit] En krijgen sowieso de client computers de DNS servers (dan wel de goede of de foute) door? Windows: ipconfig /all Linux: cat /etc/resolv.conf.

[ Voor 32% gewijzigd door PowerSp00n op 25-01-2004 15:58 ]


  • idef1x
  • Registratie: Januari 2004
  • Laatst online: 09:30
En hoe heb je je default policies voor iptables staan :? Ik zie nergens een regeltje voor je FORWARD chain staan en als de default hiervan op DROP staat....

  • PowerSp00n
  • Registratie: Februari 2002
  • Laatst online: 17-11-2025

PowerSp00n

There is no spoon

Mij lijkt dat als je de default policy van de FORWARD chain op DROP hebt staan het volgende ook niet mogelijk is:
Helaas blijkt dat de DNS adressen niet geforwarded worden, ik kan op het netwerk alleen internetten door IP nummers in te toetsen.

  • idef1x
  • Registratie: Januari 2004
  • Laatst online: 09:30
PowerSp00n schreef op 25 januari 2004 @ 16:00:
Mij lijkt dat als je de default policy van de FORWARD chain op DROP hebt staan het volgende ook niet mogelijk is:


[...]
Hmm nu je het zegt...helemaal overheen gelezen 8)7 |:(

  • Ablaze
  • Registratie: December 2003
  • Laatst online: 02-01 13:32
PowerSp00n schreef op 25 januari 2004 @ 15:52:
De opgegeven DNS servers zijn hiervanuit niet te pingen hoor (option domain-name-servers). Ook kun je in je dhcpd.conf de regels vanaf nummer 34 weg halen als je dit niet gebruikt.

[edit] En krijgen sowieso de client computers de DNS servers (dan wel de goede of de foute) door? Windows: ipconfig /all Linux: cat /etc/resolv.conf.
De DNS servers zijn goed (zie http://web.planet.nl/abon...n/serverinstellingen.html).
Ze worden ook doorgegeven, want als ik op de PC die internet dient te krijgen, die overigens Windows draait, ipconfig /all intoets, krijg ik het volgende:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
       IP-adres. . . . . . . . . . . . . : 192.168.1.254

        Subnetmasker. . . . . . . . . . . : 255.255.255.0

        Standaardgateway. . . . . . . . . : 192.168.1.1

        DHCP-server . . . . . . . . . . . : 192.168.1.1

        DNS-servers . . . . . . . . . . . : 195.121.1.34

                                            195.121.1.66

        Lease verkregen . . . . . . . . . : zondag 25 januari 2004 16:23:22

        Lease verlopen . . . . . . . . .  : zondag 25 januari 2004 16:33:22

Afgezien van het nogal vage IP adres lijkt alles goed. Het probleem blijft echter voortbestaan.

  • idef1x
  • Registratie: Januari 2004
  • Laatst online: 09:30
Lijkt er meer op dat die DNS servers niet werken? In ieder geval niet vanaf een xs4all account
Als ik die instel krijg ik geen resultaten terug (normaal draai ik zelf DNS).
Krijg je wel resultaat op je linux doos?

  • Ablaze
  • Registratie: December 2003
  • Laatst online: 02-01 13:32
idef1x schreef op 25 januari 2004 @ 16:35:
Lijkt er meer op dat die DNS servers niet werken? In ieder geval niet vanaf een xs4all account
Als ik die instel krijg ik geen resultaten terug (normaal draai ik zelf DNS).
Krijg je wel resultaat op je linux doos?
Ja hoor, ik ben dit aan het typen onder Linux (Fedora Core 1). Deze DNS servers staan onder /etc/resolv.conf en staan exact hetzelfde op de site van Planet. Misschien zit er een of andere duistere Fedora configuratie/firewall in de weg?

  • PowerSp00n
  • Registratie: Februari 2002
  • Laatst online: 17-11-2025

PowerSp00n

There is no spoon

Ablaze schreef op 25 januari 2004 @ 16:45:
[...]

Ja hoor, ik ben dit aan het typen onder Linux (Fedora Core 1). Deze DNS servers staan onder /etc/resolv.conf en staan exact hetzelfde op de site van Planet. Misschien zit er een of andere duistere Fedora configuratie/firewall in de weg?
Oeh Fedora, post toch je firewall setup maar even >:). (iptables -L en misschien ff iptables -t nat -L). Volgensmij stelt Fedora zelf standaard wel iets van een firewall in?

  • pierre-oord
  • Registratie: April 2002
  • Laatst online: 20-02 12:27
Denk idd firewallregels.
Goeie regels nodig? [spam] check m'n site[/spam]

Ondernemer in tech (oud LOQED.com, nu UpToMore.com)


  • idef1x
  • Registratie: Januari 2004
  • Laatst online: 09:30
Hmm okee dan blokkeerd planet dus de DNS voor niet planneters :(
Enfin dan maar even brainstormen....

als met tcpdump op je linux bak naar de ppp0 interface kijkt, zie je je DNS requests dan naar buiten gaan (met je publieke ip-adres) en weer terugkomen?

kun je ook even de output van : iptables -nvL en iptables -t nat -nvL anders geven?
Het lijkt me inderdaad te moeten werken, maar toch iets doet ut niet })

  • Ablaze
  • Registratie: December 2003
  • Laatst online: 02-01 13:32
PowerSp00n schreef op 25 januari 2004 @ 16:53:
[...]


Oeh Fedora, post toch je firewall setup maar even >:). (iptables -L en misschien ff iptables -t nat -L). Volgensmij stelt Fedora zelf standaard wel iets van een firewall in?
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
[root@BartServer root]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere           icmp any
ACCEPT     ipv6-crypt--  anywhere             anywhere
ACCEPT     ipv6-auth--  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere           state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:smtp
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:ftp
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:telnet
REJECT     all  --  anywhere             anywhere           reject-with icmp-host-prohibited
[root@BartServer root]# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


Hmm, er staat nogal wat in...

  • Ablaze
  • Registratie: December 2003
  • Laatst online: 02-01 13:32
idef1x schreef op 25 januari 2004 @ 16:59:
Hmm okee dan blokkeerd planet dus de DNS voor niet planneters :(
Enfin dan maar even brainstormen....

als met tcpdump op je linux bak naar de ppp0 interface kijkt, zie je je DNS requests dan naar buiten gaan (met je publieke ip-adres) en weer terugkomen?
Eens kijken... hoe kan ik dat het beste zien? Ik heb het volgende geprobeerd:

Op de Windows PC heb ik eerst even een ping gedaan naar een IP adres (zichtbaar in onderstaande dump). Vervolgens een website geprobeerd te bereiken, wat niet werkte.

[root@BartServer root]# tcpdump -i ppp0
tcpdump: listening on ppp0
17:10:29.296647 213.54.126.175.2486 > 62.131.153.243.4662: S 3154424552:3154424552(0) win 32767 <mss 1414,nop,nop,sackOK> (DF)
17:10:29.296701 62.131.153.243 > 213.54.126.175: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]
17:10:29.502393 62.131.153.243 > 81.17.59.17: icmp: echo request
17:10:29.517587 81.17.59.17 > 62.131.153.243: icmp: echo reply
17:10:30.503143 62.131.153.243 > 81.17.59.17: icmp: echo request
17:10:30.519422 81.17.59.17 > 62.131.153.243: icmp: echo reply
17:10:45.722655 62.195.236.232.50460 > 62.131.153.243.4662: S 3282269169:3282269169(0) win 64240 <mss 1460,nop,nop,sackOK>
17:10:45.722735 62.131.153.243 > 62.195.236.232: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]
17:10:48.659116 62.195.236.232.50460 > 62.131.153.243.4662: S 3282269169:3282269169(0) win 64240 <mss 1460,nop,nop,sackOK>
17:10:48.659173 62.131.153.243 > 62.195.236.232: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]
17:10:53.289184 62.131.153.243.33124 > 217.17.139.180.http: F 3566006182:3566006182(0) ack 1160345056 win 60816 <nop,nop,timestamp 127025 102776> (DF)
17:10:53.347262 217.17.139.180.http > 62.131.153.243.33124: . ack 1 win 16342 <nop,nop,timestamp 105778 127025> (DF) [tos 0x8]
17:10:53.349240 217.17.139.180.http > 62.131.153.243.33124: F 1:1(0) ack 1 win 16342 <nop,nop,timestamp 105778 127025> (DF) [tos 0x8]
17:10:53.349287 62.131.153.243.33124 > 217.17.139.180.http: . ack 2 win 60816 <nop,nop,timestamp 127031 105778> (DF) [tos 0x8]
17:10:53.535225 80.132.55.207.30079 > 62.131.153.243.4662: S 2129126286:2129126286(0) win 32767 <mss 1450,nop,wscale 0,nop,nop,sackOK> (DF)
17:10:53.535280 62.131.153.243 > 80.132.55.207: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]
17:10:53.940151 217.84.23.233.51024 > 62.131.153.243.4662: S 986189040:986189040(0) win 32768 <mss 1450,nop,wscale 0,nop,nop,timestamp 2930768017 0> (DF)
17:10:53.940228 62.131.153.243 > 217.84.23.233: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]
17:10:54.694019 62.195.236.232.50460 > 62.131.153.243.4662: S 3282269169:3282269169(0) win 64240 <mss 1460,nop,nop,sackOK>
17:10:54.694076 62.131.153.243 > 62.195.236.232: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]
17:10:56.835628 217.84.23.233.51024 > 62.131.153.243.4662: S 986189040:986189040(0) win 32768 <mss 1450,nop,wscale 0,nop,nop,timestamp 2930768023 0> (DF)
17:10:56.835685 62.131.153.243 > 217.84.23.233: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]
17:10:59.611122 80.132.55.207.30079 > 62.131.153.243.4662: S 2129126286:2129126286(0) win 32767 <mss 1450,nop,wscale 0,nop,nop,sackOK> (DF)
17:10:59.611176 62.131.153.243 > 80.132.55.207: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]
17:10:59.834081 217.84.23.233.51024 > 62.131.153.243.4662: S 986189040:986189040(0) win 32768 <mss 1450> (DF)
17:10:59.834141 62.131.153.243 > 217.84.23.233: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]
17:11:01.509774 213.54.126.175.2817 > 62.131.153.243.4662: S 3172648098:3172648098(0) win 32767 <mss 1414,nop,nop,sackOK> (DF)
17:11:01.509827 62.131.153.243 > 213.54.126.175: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]
17:11:02.829563 217.84.23.233.51024 > 62.131.153.243.4662: S 986189040:986189040(0) win 32768 <mss 1450> (DF)
17:11:02.829619 62.131.153.243 > 217.84.23.233: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]


Als ik niets doe, krijg ik toch ca. elke 2 seconden het volgende:

17:14:20.897414 81.61.207.209.1475 > 62.131.153.243.swat: S 4216889789:4216889789(0) win 65535 <mss 1440,nop,nop,sackOK> (DF)
17:14:20.897495 62.131.153.243 > 81.61.207.209: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]


Helaas kan ik uit deze dump niet zelf het probleem opmaken, omdat ik hier de kennis voor mis.

[ Voor 4% gewijzigd door Ablaze op 25-01-2004 17:17 ]


  • idef1x
  • Registratie: Januari 2004
  • Laatst online: 09:30
Hmm wel zoals ik het lees zorgt regel 15 al ervoor dat je alles accepteerd en waar dest dan nog voor is??

Kun je eens een tcpdump gedeelte laten zien op ppp0? Iets als :

tcpdump -i ppp0 port 53

je moet dan verkeer zien van jouw genatted windows bak naar een DNS server en weer terug....Vreemd dat als je op ip-adres werk dat het wel gewoon werkt.....

  • idef1x
  • Registratie: Januari 2004
  • Laatst online: 09:30
Ablaze schreef op 25 januari 2004 @ 17:17:
[...]

Als ik niets doe, krijg ik toch ca. elke 2 seconden het volgende:

17:14:20.897414 81.61.207.209.1475 > 62.131.153.243.swat: S 4216889789:4216889789(0) win 65535 <mss 1440,nop,nop,sackOK> (DF)
17:14:20.897495 62.131.153.243 > 81.61.207.209: icmp: host 62.131.153.243 unreachable - admin prohibited [tos 0xc0]


Helaas kan ik uit deze dump niet zelf het probleem opmaken, omdat ik hier de kennis voor mis.
Die laatste is in iedergeval iet wat volgens mij met samba te maken heeft. Iemand probeerd jou machine via deze poort (swat) te benaderen...

Voor de rest....dit gebeurd er dus wanneer je op naam de verbinding opzet? of op ip-adres? Zo te zien loopt er wel verkeer van en naar de webserver.

[ Voor 11% gewijzigd door idef1x op 25-01-2004 17:35 ]


  • PowerSp00n
  • Registratie: Februari 2002
  • Laatst online: 17-11-2025

PowerSp00n

There is no spoon

Dat zal wel komen omdat regel 24 alles nog even leuk rejected. Run eens lokkit en disable de firewall eens.

  • idef1x
  • Registratie: Januari 2004
  • Laatst online: 09:30
PowerSp00n schreef op 25 januari 2004 @ 17:26:
Dat zal wel komen omdat regel 24 alles nog even leuk rejected. Run eens lokkit en disable de firewall eens.
Hmm ja maar regel 15 komt voor regel 24 en die accepteerd het gewoon......Dus hoe komt ie dan uberhaupt bij regel 24?

[ Voor 7% gewijzigd door idef1x op 25-01-2004 17:36 ]


  • Ablaze
  • Registratie: December 2003
  • Laatst online: 02-01 13:32
PowerSp00n schreef op 25 januari 2004 @ 17:26:
Dat zal wel komen omdat regel 24 alles nog even leuk rejected. Run eens lokkit en disable de firewall eens.
Bedankt, dat werkte! Daarna ge-enabled en een vinkje gezet bij "Vertrouwde apparaten: eth0". De uitvoer van iptables -L is echter nog vrijwel hetzelfde, afgezien van het feit dat er nu 2 keer " ACCEPT all -- anywhere anywhere" staat? Kan iemand uitleggen wat het verschil is, want ik vind het nogal dubieus?

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere           icmp any
ACCEPT     ipv6-crypt--  anywhere             anywhere
ACCEPT     ipv6-auth--  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere           state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:telnet
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:smtp
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:ftp
REJECT     all  --  anywhere             anywhere           reject-with icmp-host-prohibited

  • Eric Oud Ammerveld
  • Registratie: December 2000
  • Laatst online: 05-07-2024

Eric Oud Ammerveld

Arduino developing... :)

Voor IPTables kan je een hele praktische console applicatie gebruiken genaamd Jay Firewall. (search http://www.google.com/linux for it)
Ik vind hem fijner werken dan lokkit en je kan er eigenlijk alles op QoS na instellen.
Het scheelt je een hoop verdiepwerk in IPTABLES

-=@@D=- Macbook Pro 16"


  • Ablaze
  • Registratie: December 2003
  • Laatst online: 02-01 13:32
AADNOLL schreef op 25 januari 2004 @ 17:54:
Voor IPTables kan je een hele praktische console applicatie gebruiken genaamd Jay Firewall. (search http://www.google.com/linux for it)
Ik vind hem fijner werken dan lokkit en je kan er eigenlijk alles op QoS na instellen.
Het scheelt je een hoop verdiepwerk in IPTABLES
Hmm, dat kan eventueel van pas komen!

Trouwens, iedereen bedankt voor het meedenken. Is het instellen van een firewall onder Linux trouwens net zo belangrijk als onder Windows?

Verwijderd

kijk ook eens naar shorewall is perfect (vind ik ;) )

  • Adze
  • Registratie: Juli 2001
  • Laatst online: 22-02 20:46

Adze

CCNP !

offtopic: (maar wel erg handig !!)

Wanneer je internet delen aan de praat hebt moet je het volgende eens proberen:

Als een computer op je interne netwerk veel bandbreedte aan het opslurpen is kan het gebeuren dat jou internet verbinding helemaal "wegzakt". Dit kun je oplossen door QoS.

Zet in je kernel alle opties voor QoS aan. Activeer queueing door het volgende in te tikken in je linux-doos:

tc qdisc add dev ppp0 root handle 1: htb default 30
tc class add dev ppp0 parent 1: classid 1:1 htb rate 512kbit burst 6k
tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 512kbit burst 6k prio 1
tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 460kbit burst 6k prio 2
tc class add dev ppp0 parent 1:1 classid 1:30 htb rate 410kbit burst 6k prio 3
tc class add dev ppp0 parent 1:1 classid 1:40 htb rate 358kbit burst 6k prio 4
tc qdisc add dev ppp0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev ppp0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev ppp0 parent 1:30 handle 30: sfq perturb 10
tc qdisc add dev ppp0 parent 1:40 handle 40: sfq perturb 10
tc filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff flowid 1:10
tc filter add dev ppp0 parent 1:0 protocol ip prio 11 u32 match ip tos 0x08 0xff flowid 1:20
tc filter add dev ppp0 parent 1:0 protocol ip prio 12 u32 match ip tos 0x04 0xff flowid 1:30
tc filter add dev ppp0 parent 1:0 protocol ip prio 13 u32 match ip tos 0x00 0xff flowid 1:40
tc filter add dev ppp0 parent 1: protocol ip prio 10 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:10

Wanneer je nu via iptables de TOS bits aanpast voor het uitgaande verkeer kun je voorkeur geven aan verkeer. (0x10 = realtime; 0x08 = high; 0x04 = normal; 0x00 = low) Voorbeeld:

Ping hoge voorkeur:

iptables -A OUTPUT -p icmp -j TOS --set-tos 0x10 (voor de linux bak)
iptables -A PREROUTING -p icmp -j TOS --set-tos 0x10 (voor de ge-"nat"-te machines)

Succes.

  • PowerSp00n
  • Registratie: Februari 2002
  • Laatst online: 17-11-2025

PowerSp00n

There is no spoon

Ablaze schreef op 25 januari 2004 @ 19:46:
[...]

Hmm, dat kan eventueel van pas komen!

Trouwens, iedereen bedankt voor het meedenken. Is het instellen van een firewall onder Linux trouwens net zo belangrijk als onder Windows?
Als jij ervoor zorgt dat je services up to date zijn en er geen onnodige services draaien hoef je opzich geen firewall te draaien.
Pagina: 1