Linux Debian routing og iptables

[choer_]

OK.

Har 2 nettverkskort.

eth0 og eth1

 

eth0:

Address: 192.168.139.139

Netmask: 255.255.255.0

Broadcast: 192.168.139.255

Network: 192.168.139.0

 

eth1:

Address: 10.0.0.3

Netmask: 255.255.255.0

Broadcast: 10.0.0.255

Network: 10.0.0.0

 

Deretter har jeg gjort følgende for å sette opp routing:

echo "1" > /proc/sys/net/ipv4/ip_forward

 

(endringer i /etc/sysctl.conf):

net.ipv4.tcp_syncookies=1

net.ipv4.conf.default.forwarding=1

net.ipv6.conf.default.forwarding=1

(lagre endringer og kjør kommando i terminalvindu):

sysctl -p

 

Laget deretter et script for å sette iptables regler, og gjorde det kjørbart:

iptables -A FORWARD -s 10.0.0.0/24 -d 192.168.139.0/24 -p tcp -j ACCEPT

iptables -A FORWARD -s 192.168.139.0/24 -d 10.0.0.0/24 -p tcp -j ACCEPT

iptables -A FORWARD -p icmp -j ACCEPT

iptables -A OUTPUT -p icmp -j ACCEPT

iptables -A INPUT -p icmp -j ACCEPT

iptables -L -n -v

 

Deretter kjører jeg scriptet, og alt settes opp rett og listes til slutt ut for meg.

 

Deretter har jeg en windows 2008 maskin koblet til 10.0.0.x nettet med ip adresse 10.0.0.1, gateway 10.0.0.3(linux maskinen), dns server 10.0.0.3(selvom dns forwarding ikke er satt på linux serveren).

 

Jeg prøver å pinge 192.168.139.139 fra windows 2008 serveren.

Alt er fint.

Jeg prøver å pinge 10.0.0.3.

Alt er fint.

Jeg prøver å pinge 192.168.139.1(dette er NAT gateway'en til nettet som har ny NAT til internett).

Request Timed out.

Prøver å pinge vg.no

Request timed out. (men jeg ser at ping har likevel klart å finne ip-adressen til vg.no)

Prøver å pinge ip-adressen direkte.

Request timed out.

Prøver å pinge alt dette fra Linux routeren.

Alt fungerer.

 

Er det noen som kan hjelpe?

[Gjest member-1768784]

-

Endret 10. april 2017 av member-1768784

[choer_]

Det har jeg nå gjort, men jeg har problemer med å finne loggen noen plass. Eller logger den ikke som den skal kanskje?

 

Jeg har prøvd å se i /var/log/syslog men der var det ingenting å finne om de reglene jeg hadde laget og gitt navn til.

 

Deretter la jeg følgende til /etc/syslog.conf :

kern.warning /var/log/iptables.log

kern.=info /var/log/iptables

kern.=debug /var/log/ipdebug

 

Har prøvd å søke gjennom filene med grep og kikke på dem med more, men finner ingenting av verdi.

 

Er det sånn at jeg må bruke drop for å logge?

Det skal vel være nok med "regel -j LOG --log-prefix "regelnavn"" ??

 

Har også kikka på /var/log/messages

Fant ikke mye av verdi der heller

Endret 31. juli 2008 av choer_

[tyldum]

Trenger ikke styre med logginga

Du kan se antall pakker og trafikkmengde som treffer en regel om du tar 'iptables -vnL FORWARD'.

Tellerne nullstilles når reglene oppdateres/endres.

 

Jeg tipper problemet ditt er rutingen tilbake fra 192.168.139.1. Har du angitt 192.168.139.139 som gateway for 10.0.0.0/24?

 

Og tcpdump er din gode venn her. På 192.168.139.139 kan du ta en 'tcpdump -i ethX -n' for å se trafikken på hver side av ruteren (X erstattes med henholdsvis 0 og 1).

[choer_]

Legger her ved 3 filer som jeg bruker som script for å oppnå og teste det jeg vil.

Før jeg kommenterer dem vil jeg kommentere noe annet.

 

* Jeg kan ikke sette ett nettverkskort tilhørende subnett 10.0.0.0/24 til å bruke gateway tilhørende subnett 192.168.139.0/24. Gatewayen må være i samme subnett med et ekstra nettverkskort i det ønskede subnettet(192.168.139.0/24). Deretter må trafikken gå via nettverkskortet i det samme subnettet (gateway for 10.0.0.0/24) og videre til nettverksort i det neste subnettet(192.168.139.0/24) over den samme maskine/gatewayen etc.

 

* Jeg har også tenkt tanken at det er svaret tilbake som er problemet, men det er ikke lett å løse. Jeg har både sett på /etc/sysctl.conf og /proc/sys/net/ipv4/ osv det som finnes der.

 

Jeg endret filtype på scriptene for å kunne laste dem opp her. Er bare å endre det igjen.

Det jeg gjorde nå sist var å kjøre ./set-iptables-simple.sh som tillater all trafikk uansett hva. Deretter kjørte jeg ./set-forward.sh og valgte 1. (Valg 2 er ikke ferdig skrevet enda, men det er ikke viktig for denne testen).

 

Via valg 1 har jeg satt opp hele /proc/sys/net/ipv4 og alt der under slik jeg vil ha det, i tillegg til at /etc/sysctl.conf allerede er satt opp. Det eneste som skjedde var at jeg ikke lenger kan surfe på linuxboksen.

 

Og akkurat den samme oppførselen som tidligere hos windows boksen.

 

Jeg fant fort ut at tcpdump ikke var i debian, jeg forsto det slik at det tilsvarte tcpd. Jeg fant ikke ut noe merkverdig via dette, heller ikke etter å ha sett i logfilene.

 

Jeg kikket på iptables -L -n -v FORWARD og uten FORWARD og så at det ble sendt pakker både INPUT, OUTPUT og FORWARD. Men fortsatt var situasjonen den samme...

set_forward.sh.txt

set_iptables.sh.txt

set_iptables_simple.sh.txt

[tyldum]

tcpd har ingeting med tcpdump å gjøre, og tcpdump er inkludert i debian.

 

Trafikkflyten din:

Win2008 -> 10.0.0.3 -> 192.168.139.1 -> [NAT]

[NAT] -> 192.168.139.1 -> 192.168.139 -> Win2008

 

Problemet ditt er mest sannsynlig at 192.168.139.1 ikke vet hvor i alle dager at 10.0.0.1 er. Så den sender trafikk til sin default gateway.

 

Det jeg nevner over er at på 192.168.139.1 må du angi en statisk rute som sier at 10.0.0.0/24 nås via 192.168.139.139.

[choer_]

Det kunne vært svaret høres det ut som ja, er bare det at 192.168.139.1 er en IP i vmWare som er gateway for NAT inn til den fysiske maskinen som har den reelle internettkoblingen.

 

Får ikke lagt til ruter på den, så vidt jeg vet.

 

Likevel skulle jeg tro at når pakker fra subnett 10.0.0.0/24 passerer Linux-routeren min og går ut på subnett 192.168.139.0/24 så endres avsenderadresse til det interface som faktisk sender. Det er hvertfall slik det fungerer i NAT, men det kan vel hende det ikke er sånn i dette tifelle? Why not??

 

Finner ikke terminalkommandoen tcpdump, systemet godtar den ikke. Men den vil godta tcpd, som man-sidene beskriver slik, blandt annet:

 

TCPD(8) TCPD(8)

 

NAME

tcpd - access control facility for internet services

 

DESCRIPTION

The tcpd program can be set up to monitor incoming requests for telnet,

finger, ftp, exec, rsh, rlogin, tftp, talk, comsat and other services

that have a one-to-one mapping onto executable files.

 

The program supports both 4.3BSD-style sockets and System V.4-style

TLI. Functionality may be limited when the protocol underneath TLI is

not an internet protocol.

 

Nå er jeg ingen ekspert, og er glad for alle svar og forklaringer jeg får.

[tyldum]

Linuxen vil ikke NAT'e automatisk, og i dine script så har du ikke angitt NAT.

Så du må enten sette opp NAT på linuxen eller ruting på VMWaren. Jeg vil anbefale deg det siste, fordi du kan støte på problemer med enkelte protokoller om du dobbelt eller trippel NAT'er.

 

TCPD er en måte å sette opp en port som er koblet til en applikasjon. tcpdump dumper all trafikk på et interface så den blir lesbar. Da ser du om trafikk går ut på rett interface, hvilke navsenderadresse den og og hvor svarene kommer fra. Mangel på svar vil som regel bety feil i ruting.

Endret 5. august 2008 av tyldum

[Admin'c]

(er du lat er arnos iptables firewall kjekk)

 

du må og skru på nat i en eller annen fil (endre fra null til en) er bare å google

[tyldum]

Nei, han trenger regler i iptables for dette

(hintet er 'SNAT')

[choer_]

hint hint ja

*erte erte* liksom..

 

skal se på det...

 

For å slippe unna NAT etter NAT etter NAT problemet prøvde jeg heller å pinge fra host OS via virtuelt nettverkskort til DEBIAN serveren i vmware, som forwarda fra 192.168.139.0 til 10.0.0.1 som var da win 2008 Serveren. Jeg la til en route på host OS (vista) som viste hvordan man skulle nå 10.0.0.0/24

 

Det var et tidligere innlegg her som antok at 192.168.139.1 ikke hadde en route til å nå tilbake til 10.0.0.x, og jeg svarte at jeg ikke kunne legge route på denne da det var en vmware workstation innebygd NAT router / virtuelt nettverkskort jeg ikke hadde noen form for konfigurasjonsmuligheter på.

 

Ved å bruke host OS i stedet og ordne route derfra i stedet ordnet det seg.

 

Takker for svar hittil.