port forward saját magamra

Sziasztok!

Tudna segíteni valaki abban, hogy ha saját magamra szeretnék portforwardolni, akkor annak mi a trükkje?
Konkrétan:

Van egy linuxos tűzfal, mögötte egy Exchange 2010. Kívülről minden szép és jó: ha beírom, hogy mail.akarmi.hu/owa, akkor szépen tudok webmailezni.
Ha magán az exchange szerveren csinálom ugyanezt, akkor jelen pillanatban a tűzfalon keresi saját magát. :(
Gyanítom, hogy a VPN-ező klienseknél ezért nem megy pl. a házon kívül...

A tűzfalscript ide vonatkozó része így néz ki:

-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.1.0.3:80
-A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.1.0.3:443
-A POSTROUTING -o eth1 -j MASQUERADE

Mit lámázok el? :)

előre is köszi a segítséget:

Adam

5912 megtekintés

Nem feltétlen válasz a kérdésre, de ezt valaki jól összerakta:
http://hup.hu/node/93287

20. oldal:
http://lok.hu/egyeb/2007mentes/eloadasok/lok-2007-netfilter.pdf

0 szavazat

A hozzászóláshoz be kell jelentkezni

Kezdjük ott, mit ad belül a DNS a mail.akarmi.hu-ra? Képzeld el fejben, merre megy a csomag, vagy ha nem megy, akkor az iptables tud szépen logolni. Nekem az iptables flow chartok is szoktak segíteni. Valószínűleg az INPUT chainben köt ki a csomag.

A legtisztább egyébként egy split-horizon DNS lenne, vagyis házon belül a mail.akarmi.hu mutasson az Exchange szerverre, szerény véleményem szerint. Így ha pl. kiesik a tűzfal, akkor is megy legalább a belső háló, meg minek átfolyatni rajta fölöslegesen a forgalmat.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Belülről is ugyanazt adja, mint kívülről (a tűzfal publikus címét). Az input lánc jelen pillanatban belülről mindent elfogad (hogy ez ne legyen most gond).
Köszi a DNS tippet, ez lett volna a következő 5letem, csak gondoltam ez is megoldható valahogy, ha már egy 4e HUF-os t-plink router alapból tudja. :)

0 szavazat

A hozzászóláshoz be kell jelentkezni

ket lehetoseget latok a megoldasra, alabb mar reszben emlitettek mindkettot:

1. a belso dns-t modositod, hogy a mail.akarmi.hu-ra a 10.0.1.3-at adja vissza. igy aki ezt hasznalja (belso gepek, vpn) az jo helyre fog menni.

2. az iptables-be csinalsz egy nat-ot ami a belso halorol erkezo es a kulso ip fele tarto csomagokat attolja a 10.0.1.3-nak. ennek a fele benne van a topic-inditoban, viszont kell meg egy snat amivel kicsereled a kliens gep ip-jet (source ip) a szerver belso ip-jere. igy nem fog megkavarodni a route-olas. hatranya, hogy igy az owa iranyaba a belso halorol indulo forgalom keresztul fog menni a tuzfal/gw-n is.

a 2. lehetoseget mar hasznaltam, bar nem teljesen a fenti felallasban es csak teszt-celbol kellett.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Pár ötlet, gyorsan:
Az eth1 gondolom a _befelé_ néző interface esetünkben. Ha a belső hálóból a belső hálóba irányítod a forgalmat, akkor a célgép a választ közvetlenül adná vissza - így viszont a forrásgép nem arról az IP-ről kap választ, mint amit megszólított, mert ezen az úton a tűzfal kimarad, így nincs lehetősége visszavarázsolni az eredeti paramétereket. Na így nem működik a dolog: a tűzfalon a kimenő csomagot maszkolni kell, hogy a válasz oda menjen vissza és így lehetőség legyen az eredeti IP cím visszaállítására. (Ha ezért szerepel itt az eth1 MASQ, akkor ez a pont pipa. :-))
A másik javaslatom, hogy nézd meg a forgalmat pl. tcpdumppal. Célszerűen szűkíts hostra/portra - különben kicsit nagy lesz a listád. ;-) (Nem kizárt, hogy a FORWARD láncon valamelyik irány elvérzik.)
Még olyat is el tudok képzelni, hogy azért van a hörgés, mert ugyanazon az interface-n jön be a csomag, mint amin ki akar menni. Egy rövid ideig volt olyan default konfig, ahol ez alapban tiltott volt. (Ez annak idején valami kernel opció volt, valahol a /proc alá kivezetve. Nem gondolnám, hogy ez a bibi - de egyszer már futottam ilyen problémára.)

0 szavazat