Iptables og webserver

jeg kikker på det og ser om jeg kan gennemskue tingene, det er dog ferietid og jeg er ikke ret meget på så der kan sagtens gå et par dage. Går der mere en 14 dage så drop lige et hallo her så jeg mindes om det

Der er noget jeg ikke helt forstår. Hvorfor prøver du med http://80.0.0.1:4000 ?
Hvordan skulle den adresse kunne give dig adgang til din webserver, som jo kører på 10.0.0.30:4000 ?

Buferzone, den er bare gofin'... Jeg kan virkelig ikke gennemskue hvad der blokere.

Janpo, jeg skriver http://80.0.0.1:4000, fordi jeg skal have fat i min interne server, som står inde på lokal netværket. Da man ikke kan skrive lokale IP adresser på Internettet, har jeg i firewall'en (som er gateway for min lokale netværk) bestemt at alt trafik som kommer på port 4000 på min yderside IP (altså min ISP IP), skal gå videre til en lokal maskine på det indre netværk (dvs. i dette tilfælde en webserver som køre på port 4000 med ip adressen 10.0.0.30). Men det virker desværre bare ikke, men hvorfor er et rigtig godt spørgsmål...

Til nysgerige sjæle kan jeg fortælle at jeg vil anvende en upriviligeret port (4000), da jeg allerede har en webserver på http://80.0.0.1 som køre på standard http porten (80). Desuden skal det nok også nævnes at den interne webserver (10.0.0.30/8) ikke er en DMZ zone, men en maskine som er tilkoblet til en switch (og switchen selvfølgelig til gateway 10.0.0.1/8).

Okay, så 80.0.0.1 var fra udenfor din router.
Har du en entry i din routing tabel fra eth0 til eth2 ?

Ja, nu er 80.0.0.1 selve routeren, da jeg anvender serveren til dette. Selve "hardware routeren" er bare sat til bridge mode, så selve routning funktionen er hvad du ser i eksempelet foroven.

Tror denne kombinasjonen er ulovlig slik at den kan få det øvrige til å fungere uforutsigbart:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Jeg tror ikke dette vil fungere slik at den fordeler trafikken ut gjennom to eksterne tilkoplinger.

Hvis du installerer den lille trafikkmonitor programmet iptraf, så vil du straks kunne se hvordan trafikken kjører. Tipper at den vil vise at den trafikken som er satt opp innefra (typisk surfing på nett) bare vil kjøre ut det ene kortet. (Det skulle ellers være meget interesant og bra om jeg tok feil, men tror det ikke.)

I utgangspunktet så er vel hele firewall så "messed up" på grunn av de to postrouting setningene, at det kan vel være at ingen ting fungerer, men uansett så går det da å forsøke å spesifisere input card for prerouting setningene:

iptables -t nat -A PREROUTING -i eth0 -p tcp -d 80.0.0.1 --destination-port 4000 -j DNAT --to-destination 10.0.0.30:4000

Hej Langbein. Ja, vi har jo haft dette oppe før :-) Jeg vil lige prøve at specificere NIC og fjerne den ene MASQUERADE, og se om det hjælper. Jeg har lidt problemer med at anvende IPTRAF, eftersom der er utrolig meget trafik igennem gateway (omkring 70 brugere)... men jeg vender lige tilbage med et resultat fra det andet.

Allerførst: "I utgangspunktet så er vel hele firewall så "messed up" på grunn av de to postrouting setningene, at det kan vel være at ingen ting fungerer, men uansett så går det da å forsøke å spesifisere input card for prerouting setningene"

Nej, for det underlige er at det ellers altid virker fint, bare ikke PREROUTING til intern maskine.

Men jeg forsøgte at slette MASQUERADE på eth1, og tilføje ETH0 prerouting reglen, men det virker desværre ikke.

Men det fik mig til at tænke på en anden ting. Da jeg har 2 forbindelser, anvendes et load balancing script som bevirker at jeg ikke kan bestemme hvilken linie der anvendes. Mon det kan være problemet til det hele? Er der ikke nogle som har erfaring med dette? Jeg forstiller mig at der kommer en forespørgelse på eth0, den kommer igennem til min maskine, vil smider et svar tilbage ud i gennem eth1... men kunne man ikke rette dette med en etablished regel? Ved ikke hvorledes den skal se ud, men var det ikke en mulighed?

Hvis det er brukt et load balancing script så vil nok dette etter all sansynlighet gripe en del inn i måten som datatransporten rundt Linux firewall, prerouting mm cil virke.

Det vil for eksempel være godt mulig å lage script som "tar tak i" datapakkene før de rekker fram til de aktuelle "hooks" eller "kontrollposter" relatert til netfilter/iptables. På denne måten så kan man godt bypasse hele Linux firewall. (Også inklusive preroting.)

Årsaken til at prerouting ikke fungerer ligger med en høy grad i loadbalansing scriptet, enten dette nå fungerer som tilsiktet eller ikke.

(Det skulle ellers vært meget interessant å sett hvordan dette er bygget opp. Har ikke sette slike script som fungerer så det skulle vært meget interessant å se hvis det funger.)

Har ellers aldri noen gang vært ute for at det har vært noe problem å få prerouting til å fungere. Det pleier å være rett fram og uten et problem. Det er ellers lett å bruke port 80 og en webserver for testing, hvis du har dette tilgjengelig.

Established eller established related regel behøver du ikke (stateful inspection) ettersom FORWARD chain allerede står helt åpen:

iptables -P FORWARD ACCEPT

Det vil i utgangspunktet ikke hjelpe mye å åpne den en gang til.

Jeg vil ellers tro at iptraf kan fungere fint selv om det dreier seg om så mye som 70 brukere. Har du forsøkt ? Det er jo ikke nødvendig å monitore når trafikken er på topp. Iptraf logger ikke data, den bare viser et forløpende oppdatert øyeblikksbilde. Man kan også se inn på trafikken på et nettverkskort av gangen, ved å føst logge inn på det ene kortet som jobber mot internet og så det andre så bør man umiddelbart kunne se om det flyter trafikk gjennom begge. Man bør vel også kunne se sånn noenlunde hvordan denne trafikken er fordelt.

Hvis du "for testing purposes" tar ut den ene nettverksadapteren pluss disablet load balancing scriptet, så tror jeg nok at prerouting vil kjøre umiddelbart.

Jeg har brugt iptraf, men det er svært at finde de rigtige pakker, når der er så meget trafik hele tiden. Jeg har dog ikke prøvet at stoppe load balancing scriptet. Men kunne være at jeg bliver nød til dette. Men jeg kunne jo evt. bare stoppe load balancing scriptet, lukke for eth1 og fjerne masquerade på eth1 for at teste. Det burde da være nok, i stedet for fysisk at fjerne eth1.

hmm, jeg faldt over denne side: http://www.sslug.dk/emailarkiv/netvaerk/2002_11/msg00085.html

Han har også load balancing, og hans ser ud til at virke (nogenlunde)... Ved ikke om det siger dig noget?