port forward

Linux-kezdő

sziasztok

Adott egy server es a serverkulso halokatyajanak 25-s portjara erkezo csomagokat atkene forwardolni a egy belso halozaton csucsulo gep 25-os portjara
ezeket probaltam de nem muxik . Hol benaztam el?

iptables -A PREROUTING -t nat -i eth1 -p tcp --dport 25 -j DNAT --to 192.168.1.45:25
iptables -A FORWARD -i eth1 -o eth0 -p tcp -d 192.168.1.45 --dport 25 -j ACCEPT

koszi sztupi

  • 3881 megtekintés

nyitva eddig is azon keresztul ment a levelezes

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-07-27 15:27 CEST
Stats: 0:00:13 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 26.13% done; ETC: 15:27 (0:00:20 remaining)
Interesting ports on flanders.delmagyar.szeged.hu (217.65.110.18):
Not shown: 1669 filtered ports
PORT STATE SERVICE
20/tcp closed ftp-data
25/tcp open smtp

( siposa v | 2007. 07. 27., p – 15:40 )

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

ez van a tuzfalban

#!/bin/bash

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

INTIF="eth0"
EXTIF="eth1"
INTIP="192.168.1.231"
EXTIP="217.65.110.18"

iptables -F
iptables -P FORWARD DROP
iptables -P INPUT DROP

#log-and-drop lanc
iptables -N log-and-drop

#nem logolni a sok szemetet
iptables -A log-and-drop -j DROP -p tcp -m multiport --dports netbios-ns,netbios-dgm,netbios-ssn,135,445
iptables -A log-and-drop -j DROP -p udp -m multiport --dports netbios-ns,netbios-dgm,netbios-ssn,42508
iptables -A log-and-drop -j DROP
iptables -A log-and-drop -j REJECT

# Barracuda
iptables -t nat -A PREROUTING -i eth1 -p tcp -d 217.65.110.18 --dport 25 -j DNAT --to 192.168.1.45:25
iptables -A FORWARD -i eth1 -p tcp -d 192.168.1.45 --dport 25 -j ACCEPT

#iptables -A PREROUTING -t nat -i eth1 -p tcp --dport 25 -j DNAT --to 192.168.1.45:25
#iptables -A FORWARD -i eth1 -o eth0 -p tcp -d 192.168.1.45 --dport 25 -j ACCEPT

# Clamav miatt kell a 10055,10056 a webmin miatt meg a 10000 port
iptables -A INPUT -j ACCEPT -s 127.0.0.0/8 -d 127.0.0.0/8
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A INPUT -j ACCEPT -m multiport -p tcp --dports 25,110,143,20,220,989,990,115,80,443,10000,10055,10056
iptables -A INPUT -j ACCEPT -m multiport -p udp --dports 161
iptables -A INPUT -j ACCEPT -s 192.168.0.0/255.255.0.0

iptables -A INPUT -j ACCEPT -s 10.8.0.0/255.255.255.0
iptables -A INPUT -j ACCEPT -p icmp --icmp-type ! echo-request

# ssh Reject 20061011
iptables -A INPUT -j REJECT -i $EXTIF -p tcp --dport ssh

ez meg routing

217.65.110.16 0.0.0.0 255.255.255.248 U 0 0 0 eth1
192.168.7.0 192.168.1.244 255.255.255.0 UG 0 0 0 eth0
192.168.6.0 192.168.1.244 255.255.255.0 UG 0 0 0 eth0
192.168.5.0 192.168.1.244 255.255.255.0 UG 0 0 0 eth0
192.168.4.0 192.168.1.244 255.255.255.0 UG 0 0 0 eth0
192.168.3.0 192.168.1.244 255.255.255.0 UG 0 0 0 eth0
192.168.113.0 192.168.1.244 255.255.255.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.114.0 192.168.1.244 255.255.255.0 UG 0 0 0 eth0
192.168.115.0 192.168.1.244 255.255.255.0 UG 0 0 0 eth0
192.168.10.0 192.168.1.244 255.255.255.0 UG 0 0 0 eth0
0.0.0.0 217.65.110.17 0.0.0.0 UG 0 0 0 eth1

Barracuda részhez pluszban: 

iptables -A FORWARD -o eth1 -p tcp -s 192.168.1.45 --sport 25 -j ACCEPT

Ha nem menne, akkor az 

iptables -P FORWARD DROP
iptables -P INPUT DROP

részt szedd ki, próbáld úgy. (Természetesen csak a teszt kedvéért, amúgy kell.)

Próbálhatod közben tcpdump-pal monitorozni mindkét interfészt, hol akad el a csomag.

( Panther v | 2007. 07. 27., p – 23:23 )

a belső gép default gw-je ugye a szerver? Ha nem, akkor nem fog menni... Csak akkor, ha még egy snat-ot is megejtesz.

Nem a leanyazo fekvese a kovetkezo.
Van nekunk egy mail serverunk egy publikus ip cimmel (217.65.110.18) na erre jonnek a levelek . Hanem kitalaltak nekem ,h uzemeljunk be egy barracuda hw spam filtert (ez meg benn csucsul a mi belso halozatunkon x.x.x.45-os ip cimmel). Na a leveleket nekem et kene forwardolnom a barracuda 25-os portjara ami benn van a belso halon ez megvizslatja es tovabbitja a mailserver belso labara (x.x.x.231).A belso halon a gw a x.x.x.232.
A mailserver firwall scriptjeben most ez van benne :

# Barracuda
iptables -t nat -A PREROUTING -i eth1 -p tcp -d 217.65.110.18 --dport 25 -j DNAT --to 192.168.1.45:25
iptables -A FORWARD -i eth1 -p tcp -d 192.168.1.45 --dport 25 -j ACCEPT
iptables -A FORWARD -o eth1 -p tcp -s 192.168.1.45 --sport 25 -j ACCEPT

A barracuda forgalmat nem tudom a tcpdump-al teszetelni , csak a logban keresgelem a forgalmat (jott e be level filterezte-e . ill a level header-jeben kene latnom ,h jart e a barracudan ) de nemm latnam , h mennenek e a levelek.

Bar a level meg nem erkezik meg a mailservere.

no várj, kezdem nem érteni:

a 231 végülis maga a mail szerver (aminek van egy külső IP címe is, tehát internetről elérhető). Ez a gép fogadja a leveleket, és tárolja, stb, csak van egy hardveres spamszűrő is. Ha a mailszerveren postfix van, akkor előbb fogadja a leveleket, majd pedig átküldi a hardveres jószágnak, amely visszaküldi azokat egy másik portonl. Pont mint az amavisd-new esetén. Legalábbis nekem ez lenne a természetes...

Ezzel szemben a leveleket nem fogadod a 231-en, hanem egyből továbbküldöd a 45-nek...

Ahhoz, hogy menjen ugye, a 231-re kellene visszaküldeni a csomagot, nem a 232-re. A SYN csomag még a 231-ről megy a 45-re, de a válasz (SYN+ACK) a route tábla figyelembe vételével már a 232-re, ami azt jelenti, hogy a 231 soha nem kapja meg, s így a TCP kapcsolat nem tud kiépülni.

a DNAT szabály jó a 231-en, de... jelen eseten meg kell mondani a 231-esnek, hogy a 45-öst a 232-n érje el, és a 232-n ennek megfelelően módosítani a szabályokat:

231:
root# ip route add 192.168.1.45/32 via 192.168.1.232

232:
root# iptables -A FORWARD -i eth0 -o eth0 -d 192.168.1.45 -p tcp --dport 25 -m state --STATE NEW,ESTABLISHED -j ACCEPT

A többit szerintem kitalálod...

A prerouting lánc csomagszintű route-olást tesz lehetővé - a route tábla kicsit kevesebbet enged meg.

Itthon a routeremen is így használom a preroutingot, történetesen tesztkörnyezet gyanánt üzemeltetek postfix kiszolgálót is, és a postfix alapértelmezett átjárója a router.

Ohh medveanyam akkor most mit hova irjak ???
Azon gondolkoztam az ejjel , h a 232-t nem kene kihagyni ebbol. Ui ez az atjaro a belso halo es a internet kozott , de a mailserver egyik laba kinn a neten (217.65.110.18) a masik meg a belso halon (192.168.1.231)tehat ha a mailserver a belso halora forgalmaz akkor nem hasznaja szerintem a 232-t

flanders:~# traceroute 192.168.1.45
traceroute to 192.168.1.45 (192.168.1.45), 30 hops max, 40 byte packets
1 192.168.1.45 (192.168.1.45) 0.287 ms 0.129 ms 0.103 ms
inne gondolom.
Ha tevednek akkor lecci javitsatok ki .

Koszi Sztupi

( sibidiba | 2007. 07. 28., szo – 12:14 )

ilyesmivel én is szívtam...

Próbáld meg kívülről is letesztelni, lehet, hogy már működik, csak belülről nézve ez nem látszik, ugyanis:

iptables -A PREROUTING -t nat -i eth1 -p tcp --dport 25 -j DNAT --to 192.168.1.45:25

Ha belülről teszteled, a csomag nem eth1 -en fog megérkezni, és akkor ez a rule nem bizony matchol.

( siposa v | 2007. 07. 31., k – 13:37 )

Az nem értem, hogy ha van tűzfalad, akkor miért van külön a neten a mailserver is?

Atgondoltam más szemszögből. Nem tudom, működik-e, egy próbát talán megér.

Eddig azért nem ment, mert a tűzfaladon akart a B. kifelé küldeni (mert az a def gw), ott viszont valszeg ez nem volt megengedett.

Tehát maradjon a DNAT a levelezőszerveren, úgy ahogy eddig volt, legyen a B. gw-je a tűzfal, ÉS a tűzfalon ki kell engedned a csomagokat (-s 192.168.1.45 --sport 25) VALAMINT kell ugyanezen csomagokra SNAT is, hogy a forrás címét átírja a levelezőszerverére, mintha az küldte volna ki.

A routered azt látja majd, hogy a mailszervernek változik a MAC-je.

B. változat, ez biztos működik, de jobban szét kell szedni a netet:

Mailszervert berakod a tűzfal mögé, belső IP-re (mondjuk 1.40). Egyik hálókártya innentől felesleges, tűzfal nem kell rá.

mailszerver régi IP-jét vagy berouteolod a tűzfal mögé, vagy tűzfal külső interfészére felveszed alias-nak (eth0:1). Teljesen mindegy, mert úgyis csinálsz egy DNAT-ot, ami a 25-ös portra érkező csomagokat nyomja a Barr. felé. Barr-ában az SMTP szervert átállítod 1.40-re, valamint tűzfalban SNAT-ot csinálsz az 1.40 felől érkező csomagokra, hogy felvegyék a mailszerver IP-jét.

(ha be birod route-olni a mailszerver IP-t a tűzfal mögé, akkor a mailszerver megtarthatja az külső IP-jét, és nem kell a SNAT sem)

Eddig azért nem ment, mert a tűzfaladon akart a B. kifelé küldeni (mert az a def gw), ott viszont valszeg ez nem volt megengedett.

Igen amint a B-n atirtam a def gw-t mar jottek is a levelek.
Viszont ha kuldeni akarok akkor azt csak a mailserverrol tennem B-t kihagynam belole.
Igy akkor hogy modosul az alabbi iptables ??

# Barracuda
iptables -t nat -A PREROUTING -i eth1 -p tcp -d 217.65.110.18 --dport 25 -j DNAT --to 192.168.1.45:25
iptables -A FORWARD -i eth1 -p tcp -d 192.168.1.45 --dport 25 -j ACCEPT
iptables -A FORWARD -o eth1 -p tcp -s 192.168.1.45 --sport 25 -j ACCEPT <-- ez biztosan kell akkor bele ?

meg mindig ezen szenevedek es kezden utalni az osszes vizi ragadozot.
Az ujabb fejlemeny(?) ha visszallitom a tuzfalat es smtp-nek a mailserver belso ipcimet adom meg akkor siman megy ki,be a levelezes . De nekem a kulso ip kene , mert , kivulrol is hasznalluk a mailservert
Esetleg vkinek ujabb otlet ?

Koszi
Sztupi

Bár már írtam egyszer, de válasz nélkül maradt: próbáltad már az eredeti konfigot kívülről tesztelni?

ilyesmivel én is szívtam...

Próbáld meg kívülről is letesztelni, lehet, hogy már működik, csak belülről nézve ez nem látszik, ugyanis amit írtál

iptables -A PREROUTING -t nat -i eth1 -p tcp --dport 25 -j DNAT --to 192.168.1.45:25

szerint ha belülről teszteled, a csomag nem eth1 -en fog megérkezni, és akkor ez a rule nem matchol, és nem lesz DNAT-olva, pedig 'kívülről' nézve nagyon is jól működik.

kivulrol jonnek a csomagok aakor is ha a iptablest modositom a kovetkezokre:

iptables -t nat -A PREROUTING -i eth1 -p tcp -d 217.65.110.18 --dport 25 -j DNAT --to 192.168.1.45:25
iptables -A FORWARD -i eth1 -p tcp -d 192.168.1.45 --dport 25 -j ACCEPT
iptables -A FORWARD -o eth1 -p tcp -s 192.168.1.45 --sport 25 -j ACCEPT

a belso halon tudok is levelezni csak kifele nem megy gonolom azert mert a klienseken a mailserver kulso ipcime van megadva smtp-nek de viszont a portforward a kulso if erkezo csomagokat egybol tolja a barracuda fele , ha a kliensen a mailserver belso ip cimet allitom be smtp-nek akkor megy ki ,be a levelezes.

VAloban kivulrol mukodik de nekem leveleket is kell kuldem

Hali All !

Megoldoattam . Az archivum kedverert:

A belso halorol ill az alhalokrol a mailserver belsi if-t adtam meg smtp kiszolgalonak. Ehhez kellet meg a tuzfalban egy PREROUTING , a kulso halokrol meg a levelezeskor a szolgaltato smtp kiszolgalojat hasznaljak . pop3 nak meg minket . A fent leirt PREROUTING-al meg mukodik a barracuda rendben .

Koszi mindenkinek a segitseget

Sztupi

( budacsik | 2007. 10. 30., k – 14:52 )

Hi!

Most próbáltam ki először a port forward-ot, de nem megy persze

A célgép a 192.168.2.40-es gép a gwés szerver+tűzfal is egyben a 192.168.2.1.

A kliensek is a belső hálón vannak 192.168.2.100-200-ig.

A szerveren kiadott szabályok:
# ezt az INPUT lánc elé tettem, ez a legelső szabály
iptables -t nat -A PREROUTING -d 192.168.2.1 -p tcp --dport 220 -j DNAT --to-destination 192.168.2.40:220
# ezt pedig a forward lánc legvégére, ez a log-ból derült ki, hogy kell, mert ilyen csomagokat eldobott
iptables -A FORWARD -d 192.168.2.40 -p tcp --dport 220 -j ACCEPT

A 192.168.2.40-es gép policy-je ACCEPT volt, de gyorsan beítam pár szabály és loggoltam is mindent, hogy lássam mi történik ott. Megkapja a neki szánt csomagokat. Vissza felé nem jön, valahol elakad, csak az a baj, hogy log nélkül. Pedig most minden láncon bekapcsoltam a legvégén a log szabályt.

Szerintetek nem jó amit fent írtam szabályok, vagy hiányzik még valami, vagy csak egy régebbi szabály miatt elakad a visszafelé haladó csomag, és ezért nem kapok logot?!

Szerk.: ja, és hogy is nézne ki ami nem talál vissza?! (2.121 vagyok én)
a szervernek FORWARD láncába -s 192.168.2.40 -d 192.168.2.121 --sport 220 kb. ilyen?
Csakmert ha tudom, könnyebb megtalálni mi foghatja meg.

megnéztem, hogy amit a FORWARD-ban log nélkül droppolok az ez:
# internet felől a LAN felé NEW csomagok DROP
iptables -A FORWARD -i eth0 -o eth1 -m state --state NEW -j DROP

minden más DROP szabály loggolva is van. Tehát a csomagom nem veszhet el itt, mert az nem is NEW, és nem is az eth0 felé megy. Az én csomagom ugyebár LAN felől LAN felé megy.

Próbáljak ki a FORWARD első szabályaként egy:
iptables -A FORWARD -i eth1 -o eth1 -j ACCEPT
??

Szia!
Azóta már ilyenre módosítottam:
iptables -t nat -A PREROUTING -p tcp --dport 220 -j DNAT --to-destination 192.168.2.40:220

Egyszerűen azt kivettem belőle, de szerintem oda a local IP kell, nem?!
Mert beövő csomag aminek a célja a 192.168.2.1 (szerver) célportja a 220, azt továbbítja (DNAT) a 192.168.2.40 220-as portjára.

Lényeg, hogy így se ment.

Szerk.: ja lehet félreértettelek. A local egyben a külső is egyben ezesetben, mert minden cak az alhálón van, fentebb leírtam már részletesebben is. De végülis ennek így mennie kellene, hogy kivettem a -d részt, mert a forward-nak mennie kell ha kinntről próbáljuk és ha bennről akkor is.
Ugyan itt bent beírhatom a böngészőbe, hogy 192.168.2.40:220, de kényelesebb a usereknek innen is és otthonról is a server.domain:220-t beírni

Szerk2: meg szerintem nem azzal van a baj, mert a célszerver megkapja a csomagok a 220-as protjára, de vissza hozzám nem találnak anak válaszcsomagjai. Nyomtalanul tűnnek el.

Nah, a célszerveren (2.40) loggolom az OUTPUT-nak ESTABLISHED,RELADTED ACCEPT szabályát, hogy megnézzem a válaszcsomagokat, és az amit mondok:

SRC=192.168.2.40 DST=192.168.2.121 PROTO=TCP SPT=220 ACK SYN

Tehát ez a legelső csomag amit többször próbál küldeni. Ha jól sejtem ez a TCP ablakozás 2. lépése (->SYN,<-ACK SYN ...)
A lényeg, hogy a célszerver megkapja a megfelelő csomagot, és válaszol is, de a gw-en (192.168.2.1) ez elveszik.
Ez a csomag a FORWARD láncba jönne ugye?

Na jó, szakadjunk el a konkrét IP címektől. A belső hálón a gateway IP-je legyen A, a kliensgépé pedig B. Van az Internet vagy nemtoménmi felé is egy címe az gateway-nek: KULSO.

Akkor a gw szabályai ezek:
iptables -A PREROUTING -t nat -d $KULSO -p tcp --dport 220 -j DNAT --to-destination $B
iptables -A FORWARD -d $B --dport 220 -j ACCEPT

HA $A = $KULSO, akkor még kell:
iptables -A POSTROUTING -t nat -d $B --dport 220 -j SNAT --to-source $A

Szia!

Betettem az SNAT szabályt is. Mostmár működik, köszönöm szépen, de még kellett két szabályt betennem:

iptables -A OUTPUT -d BELSOHALO/24 -p icmp -j ACCEPT (pontosabban csak azz ICMP TYPE 5 kell, de majd rákeresek ezt hogy kell megadni, nem kell az összes ICMP-t engedni.)

iptables -A FORWARD -s $B -p tcp --sport 220 -j ACCEPT
Ez is kellett még.

Tehát a végső megoldás, ha valakinek kell:

iptables -A PREROUTING -t nat -d $KULSO_IP -p tcp --dport 220 -j DNAT --to-destination $B:220
iptables -A POSTROUTING -t nat -d $B -p tcp --dport 220 -j SNAT --to-source $A
iptables -A OUTPUT -d BELSOHALO/24 -p icmp -j ACCEPT
iptables -A FORWARD -d $B -p tcp --dport 220 -j ACCEPT
iptables -A FORWARD -s $B -p tcp --sport 220 -j ACCEPT

Kicsit sokallom az 5 rule-t, de ahol lehet szigorítani kell rajta és jó lesz szerintem.

Most még azon gondolkodom, hogy ezeknek hol kell lenniük, mert a sorrendsszámít. Jelenleg az első két szabály a legelső a tűzfal szkriptemben, vagyis pont az INPUT lánc első szabálya előtt vannak.

A 3. szabály az OUTPUT lánc elso szabálya az lo-s és ICMP-s szabályok után.

a 4. és 5. szabály a FORWARD lánc első kettő szabálya. Biztosra mentem. De szerintem ezek így jók is.

Köszi mégegyszer.

iptables -A FORWARD -d $B -p tcp --dport 220 -j ACCEPT
helyett
iptables -A FORWARD -d $B -m state --state NEW -p tcp --dport 220 -j ACCEPT

A FORWARD lánc legelső szabálya lehet:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

Ekkor minden kiépült kapcsolat működik, már csak az újakat kell engedélyezni, amire példa a fenti parancs.

-m icmp --icmp-type 5 amúgy, a help pedig:
iptables -m icmp -h
(
ha target leírása érdekes:
iptables -j SNAT -h
)

( budacsik | 2008. 02. 16., szo – 13:33 )

Udv!

Bocsi, hogy ide irom, mert ez is port forward, de ssh-val

Adott egy szerver, aminek a 25-os, es 143-as portjat forwardolnam localhostra.
A man alapjan (ssh -f -N -L ....) mukodik, de csak egyet tudok forwardolni egy parancsal, de ugye kettot (vagy tobbet[:80]) szeretnek :)
-
budacsik

Valoszinuleg a jelszokeres miatt, de nem mukodik.
Ha beirom a jelszot akkor egy port forward ok, ha abbol kilepek, akkor keri a jelszot, es a masodik port forward is ok.

Putty-al lehet egy kapcsolat alatt tobb portot forwardolni, gondoltam ssh-val is lehet, de az zavarna ha 4-5 portot akarok forwardolni akkor annyiszor legyek belepve a szerverre...
-
budacsik

Szerintem inkább az a cél, hogy egy tunnelen belül legyen a két port forward. Bár a manban nincs rá utalás, de a több -L [bind_address:]port:host:hostport formában megadott port forwardja is működik. Fontos, hogy a -L is szerepeljen mindegyik előtt.
Tehát: ssh -f -N -L ... -L ... host

Yes! Thx...

ssh -f -N -L 3025:localhost:25 -L 3143:localhost:143 username@server.name.com

tcp6 0 0 ::1:3143 :::* LISTEN
tcp6 0 0 ::1:3025 :::* LISTEN

Szerk: ez mar nem ide tartozik, de meg azt is szeretnem megoldani, hogy akkor induljon a port forward, ha elinditom a Thunderbirt-et :)
Betettem az elso sorba a /usr/bin/thunderbird file-ba. Szepen mukodik, de a thunderbird bezarasakor valahogy a port forward kapcsolatot is le kellene zarni.
-
budacsik