configuratie iptables

[Verwijderd]

Ik wil een NAS (Lacie ethernet disk raid) beschikbaar maken voor twee netwerken: een wireless netwerk en een bekabeld. De NAS heeft geen wireless netwerkadapter en ik wil hem niet hacken/aanpassen. Ook is het essentieel dat er geen directe verbinding ontstaat tussen het wireless en het bekabelde netwerk.

Wel hebben we een Suse 11.1 server die verbonden is met beide netwerken. Deze gebruikt eth0 om verbinding te leggen met het bekabelde netwerk en wlan0 om op het wireless netwerk te komen. eth1 is nu via een crosswire kabel verbonden met de NAS storage. ascii diagrammetje:

code:

       NAS
         |
         | 
         |eth1
   Suse server
   |wlan0     |eth0
   |          |
   |          |
wireless   bekabeld
  LAN          LAN

IP adressen:
eth0: 10.85.1.81
eth1: 192.168.0.111
wlan0: 172.18.13.62


Om dit op te zetten heb ik het volgende geprobeerd:

port forwarding aan door in sysctl.conf "net.ipv4.ip_forward = 1" toe te voegen en te laden met sysctl -p
in iptables, forward chain het volgende toegevoegd:

code:

    0     0 ACCEPT     all  --  eth1   wlan0   anywhere             anywhere            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  eth1   eth0    anywhere             anywhere            state RELATED,ESTABLISHED
   20  1680 ACCEPT     all  --  wlan0  eth1    anywhere             anywhere
    0     0 ACCEPT     all  --  eth0   eth1    anywhere             anywhere

en vervolgens op een PC in het wireless netwerk een route toegevoegd naar de NAS (ip 192.168.0.1) door de suse server te gebruiken als gateway.

route add -net 192.168.0.1 netmask 255.255.255.255 gw 172.18.13.62

als ik vervolgens ping vanaf die PC naar 192.168.0.1 dan komen de packages wel op de Suse server, gezien de 20 packages in bovenstaand iptables fragmentje (gelijk aan en oplopend met het aantal ping packages verzonden). Ik krijg echter geen respons van de NAS.

Wat doe ik fout?

[TrailBlazer]

default gateway op de NAS?

[Verwijderd]

default gateway op de NAS staat ingesteld op het ip van eth1: 192.168.0.111. Het is overigens mogelijk de NAS vanaf de suse server te benaderen.

[TrailBlazer]

Probeer op je suse server eens te pingen vanaf het wlan ip 172.18.13.62 is een optie in ping om een andere source te gebruiken. Standaard zal de uitgaande poort als source gebruikt worden.

ping -l 172.18.13.62 192.168.0.1

[ Voor 9% gewijzigd door TrailBlazer op 01-07-2009 11:00 ]

[Verwijderd]

ping -l 172.18.13.62 192.168.0.1 op de server werkt.

[TrailBlazer]

hmm dat is wel vaag kan je voor de zekerheid
iptable -nvL en
iptables -nvL -t nat
doen
eventueel nog even tcpdump -i eth0 icmp

[Verwijderd]

iptables -nvL:

code:

Chain INPUT (policy ACCEPT 162M packets, 154G bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 20 packets, 1384 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  eth1   eth0    0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  eth1   wlan0   0.0.0.0/0            0.0.0.0/0
    7   588 ACCEPT     all  --  wlan0  eth1    0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  eth0   eth1    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 161M packets, 150G bytes)
 pkts bytes target     prot opt in     out     source               destination

iptables -nvL -t nat:

code:

Chain PREROUTING (policy ACCEPT 331K packets, 66M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 9724 packets, 1219K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 9709 packets, 1218K bytes)
 pkts bytes target     prot opt in     out     source               destination

verder neem ik aan dat je bedoelde: tcpdump -i wlan0 icmp of tcpdump -i eth1? Als ik dat doe en ping vanaf de PC, volgt dit voor wlan0:

code:

11:38:20.241091 IP 172.18.0.191 > 192.168.0.1: ICMP echo request, id 19743, seq 1, length 64
11:38:21.664178 IP 172.18.0.191 > 192.168.0.1: ICMP echo request, id 19743, seq 2, length 64
11:38:22.254411 IP 172.18.0.191 > 192.168.0.1: ICMP echo request, id 19743, seq 3, length 64
11:38:23.250082 IP 172.18.0.191 > 192.168.0.1: ICMP echo request, id 19743, seq 4, length 64
11:38:24.247973 IP 172.18.0.191 > 192.168.0.1: ICMP echo request, id 19743, seq 5, length 64

En op eth1 ook:

code:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:40:06.353329 IP 172.18.0.191 > 192.168.0.1: ICMP echo request, id 21279, seq 1, length 64
11:40:07.385435 IP 172.18.0.191 > 192.168.0.1: ICMP echo request, id 21279, seq 2, length 64
11:40:08.383843 IP 172.18.0.191 > 192.168.0.1: ICMP echo request, id 21279, seq 3, length 64
11:40:09.487965 IP 172.18.0.191 > 192.168.0.1: ICMP echo request, id 21279, seq 4, length 64
11:40:10.377101 IP 172.18.0.191 > 192.168.0.1: ICMP echo request, id 21279, seq 5, length 64

[ Voor 7% gewijzigd door Verwijderd op 01-07-2009 13:55 ]

[TrailBlazer]

en als je die twee pings vanaf je server doet en meekijkt met tcpdump.

[Verwijderd]

ping -l 172.18.13.62 192.168.0.1:

tcpdump -i wlan0 icmp ontvangt niets (lijkt me correct?)

tcpdump -i eth0 icmp: kleine bloemlezing

code:

11:50:40.475447 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 26634, seq 104, length 64  
11:50:40.475456 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 26634, seq 161, length 64
11:50:40.475479 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 26634, seq 162, length 64
11:50:40.475477 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 26634, seq 105, length 64  
11:50:40.475505 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 26634, seq 106, length 64  
11:50:40.475514 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 26634, seq 163, length 64
11:50:40.475533 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 26634, seq 164, length 64
11:50:40.475536 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 26634, seq 107, length 64  
11:50:40.475563 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 26634, seq 165, length 64
11:50:40.475566 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 26634, seq 108, length 64  
11:50:40.475594 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 26634, seq 166, length 64
11:50:40.475601 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 26634, seq 109, length 64  
11:50:40.475625 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 26634, seq 167, length 64
11:50:40.475640 IP 192.168.0.1 > 192.168.0.111: ICMP echo reply, id 26634, seq 110, length 64  
11:50:40.475652 IP 192.168.0.111 > 192.168.0.1: ICMP echo request, id 26634, seq 168, length 64

[TrailBlazer]

hmm waarom pakt hij niet de source van 172.18.13.62. Dat zou die wel moeten doen namelijk.

[roeleboel]

route add -net 192.168.0.1 netmask 255.255.255.255 gw 172.18.13.62

Nu is mijn route-kennis zéér roestig, maar klopt dat netmask wel?
beperk je hiermee de forwarding niet tot 192.168.0.1, ipv 192.168.0.* (wat je eigenlijk wil)
Moet je hier geen netmask 255.255.255.0 hebben?

[Warbringer]

roeleboel schreef op woensdag 01 juli 2009 @ 12:21:
[...]


Nu is mijn route-kennis zéér roestig, maar klopt dat netmask wel?
beperk je hiermee de forwarding niet tot 192.168.0.1, ipv 192.168.0.* (wat je eigenlijk wil)
Moet je hier geen netmask 255.255.255.0 hebben?

Klopt. Als je bijv. 192.168.0.0/24 wil dan is je netmask 255.255.255.0.
Misschien dat http://www.subnet-calculator.com/ ook wel handig is.

[TrailBlazer]

er staat toch nergensdat hij dat wil. Hij wil enkel de Lacie bereiken alleen die antwoord niet.

[Verwijderd]

Inderdaad, alleen de Lacie hoeft bereikt te worden, ik hoef met de route dus niets anders dan 192.168.0.1 te kunnen bereiken. De -net optie in de route is dus wellicht overbodig.


UPDATE:

Het probleem is opgelost: alle instellingen op de server waren wel ok, zoals hier ook geconcludeerd, alleen bleek dat op de NAS kast weliswaar het gateway IP ingesteld stond, maar niet gebruikt werd omdat ergens anders nog ingesteld stond dat hij DHCP moest gebruiken Packages kwamen dus wel aan maar kwamen niet terug, en de reden dat het pingen vanaf de server wel lukte is dat daarvoor het gateway-IP niet van belang is. In ieder geval bedankt voor de hulp bij het oplossen!

Wel heb ik nog vragen mbt de veiligheid: de oplossing vanuit de startpost werkt wel maar forward alles. Nu zijn beide netwerken afgeschermd en kan er dus niet teveel mis gaan, maar toch is het slordig. Of niet? Is het nodig om verdere veiligheidsmaatregelen te nemen, zoals poorten specificeren (alleen samba poorten en http) enzovoorts?

[ Voor 70% gewijzigd door Verwijderd op 01-07-2009 15:36 ]

[TrailBlazer]

ze ik toch default gateway
Ik zou enkel verkeer van en naar het internet filteren voor veiligheid de rest is nice to have

[webfreakz.nl]

TrailBlazer schreef op woensdag 01 juli 2009 @ 18:15:
ze ik toch default gateway
Ik zou enkel verkeer van en naar het internet filteren voor veiligheid de rest is nice to have

Tot dat zijn WLAN gehaxxed wordt?

[laurencevde]

Ik zou nog wel host-en-doel-ip-adressen limiteren tot datgene wat correct is. Je weet maar nooit wat iemand allemaal verzint.

Als een potentiële aanvaller je WLAN binnenkomt, en je NAS weet binnen te dringen (en het is maar de vraag of-ie goed beveiligd is en geen lekken bevat), is-ie natuurlijk ook compleet binnen...

Misschien ook een beetje aandacht aan IPv6 geven. Ik weet niet of je NAS IPv6 ondersteunt, maar je suse-server wel, en wellicht meeste andere computers in je netwerk intussen ook. Nu staat IPv6-forwarding wellicht ook nog wel uit, maar het kan interessant zijn om dat ook te kunnen gebruiken.