Ip forward, iptables, subdomain

Debian GNU/Linux

Sziasztok!

Röviden a kiindulási pont. Van két hálózati kártya a gépben. Az egyik az interneten csücsül a másik pedig a belső hálózatot táplálja. A natolás működik, portforwardok is működnek. Amit szeretnék elérni, hogy bejövő kérés esetén, ha pl bacsi.geza.hu-ra érkezik bármilyen kérés akkor azt a belső hálón egy adott IP-re forwardolja. Abból indultam ki, hogy apachal vhostokban lehet ilyesmit játszani, de nekem teljes IP forward kellene. Kérdés az, hogy iptables fel tud e dolgozni ilyet, hogy bacsi.geza.hu?

Ilyesmiket találtam a neten, de nem futnak le:

iptables -t nat -A PREROUTING -d geza.geza.hu -j DNAT --to-destination 192.168.0.155
iptables -t nat -A POSTROUTING -j MASQUERADE

Szeretném iptables-szel megoldani a helyzetet. Lehetséges?

Köszönöm előre is.

üdv
ab

  • 2669 megtekintés

( ScOut3R | 2015. 07. 20., h – 11:26 )

Az iptables csomagszoru, vagyis O nem fog foglalkozni azzal, hogy milyen domain-re jott a keres, mert nem tud rola. Amit Te szeretnel, ahhoz proxy kell HTTP forgalom eseten.

ftp connection tracking eppenseggel pont van iptables-ben, pl. adatcsatornak kapcsolathoz rendelesehez. igy ha beengeded mondjuk a 21-es portot es van ftp conntrack rendelve ehhez, akkor az ftp szerver altal nyitott adatcsatornak 'RELATED' allapotouak lesznek igy lehet engedelyezni anelkul hogy a port folyamatosan nyitva lenne.

nem keverem, pl az ftp pont ilyen, így találja ki, hogy a data az related. Mondjuk nem külön helyre irányítja (mivel a conntrack modulok nem erre valók), pusztán azt szerettem volna cáfolni, hogy ha layer7 info kell a döntéshez, akkor mindenképp proxyzni kell, mert ez nem igaz. Őszintén szólva rég csináltam ilyet iptablessel, lehet, hogy nincs modul hozzá, elméleti szinten jegyeztem meg inkább.

ftp-nel a protokoll nem tamogat nev szerinti azonositast (ellentetben a http-vel ami igen) ezert ez alapbol eselytelen.
vissza a topikhoz: iptables valoban nem tud ilyet meg http-nel sem (ahol tamogatott protokoll szinten), de altalanossagban nem igaz amit irtal, miszerint az iptables nem nujt semmilyen protokollszintu tamogatast.

illetve annyiban tényleg megkövetem nat kapcsán (illetve tulajdonképp endpoint selection kapcsán) a kollégát, hogy ott ez egy csomószor valóban nem fog menni csak a csomagból kiszedett infora támaszkodni, pl mert valakinek le kéne focizni a tcp handshaket payload előtt, és akkor valóban fel vinni L7re.

( reisch | 2015. 07. 20., h – 11:36 )

esetleg ha fixek a domain-ek mögötti ip-k akkor NAT-olhatsz
és cseréled a valami.geza.hu-t ipcímre

illetve a 2 hálókártyás gépen hosts file-ba felveszed a valami.geza.hu-t a belső ip címmel

( kroozo v | 2015. 07. 20., h – 12:10 )

Attól függ. Az iptables old fel ilyesmit, de csak induláskor. Szóval semmi dinamizmust nem tud magától. Valami periodikusan updatelődő dolgot még esetleg lehetne, de arra, amit te szeretnél szerintem nem lesz jó.

Igazából egyébként is hibás az elképzelésed (feltéve, hogy jól értem mit szeretnél), mivel az alapján, hogy a bacsi.geza.hu-nak szólt-e valami, eleve csak akkor lehet kezdeni valamit, ha ez az info rendelkezésre áll a sessionben (mint pl a httpnél teszi ezt), ez pedig nem jellemző. Egy random ping mondjuk először névfelold, aztán küld ping csomagot ipre, és abban már egy szó nem lesz arról, hogy ez bacsi.geza.hu-nak szólt. És ez még számos protokollra igaz (számosra meg, mint pl a https ugyan nem, viszont ott csak layer7en proxyzva -- man in the middle -- fogsz tudni belenézni, mert egyébként a titkosított csatorna tartalmát nem látod.

Szóval ha nagyon ez kell, akkor nem sok mese van, kell több publikus ip.

( mauser1 v | 2015. 07. 20., h – 14:04 )

A belső halókártyán mi szolgálja ki a DNS kéréseket?

( AndrewBoy | 2015. 07. 21., k – 10:28 )

Köszönöm a sok választ:) Akkor kicsit körbeírom, hogy miről van szó:
A natolás mellett a belső hálóra bind van, tehát a natolt eszközök először a tűzfalat érik el, gateway és dns is ez a tűzfal (két hálókártyával).
Azt már látom, hogy iptables erre képtelen lesz.

A felállás a következő:
2 hálókártya a tűzfalban, eth1 net, eth0 belső natolt háló.

geza.hu ipje: 1.2.3.4 ez az ipje az eth1-nek a tűzfal gépben.
bacsi.geza.hu ipje: 1.2.3.4, ugye ez van megadva, mert a belső hálón lévő natolt gépnek csak belső ipcíme van, 192.168.0.123.

Azt szeretném, hogy kívülről a bácsi.géza.hu esetén a tűzfal a bejövő bácsis kéréseket átirányítsa 1-1ben a 192.168.0.123-ra.
Apache-val játszottam már ilyet, de ugye http request esetén átjön szépen, hogy mi volt a teljes request és ez működik...

Ezt a haproxyt néztem, de ez is mintha csak httpre lenne feltüzelve...

Valszeg nem kivitelezhető? Publikus ip cím kéne a belső gépre is?

Azt szeretném, hogy kívülről a bácsi.géza.hu esetén a tűzfal a bejövő bácsis kéréseket átirányítsa 1-1ben a 192.168.0.123-ra.

Csak adott port (protokoll) esetében, vagy MINDEN csomagot?

Ha minden csomagot, akkor 1:1 külső-belső megfeleltetés kell.
Ha nem minden csomagot, akkor még akár működhet is.
Ha csak http esetén, akkor megoldható portfwd-al v reverse proxy-val

Azon felül pedig generikusan max annyit lehet tenni, hogy bizonyos portrangeket egy az egyben oda teszel.

Szerintem gondold át, hogy valóban az-e az igény, hogy minden csomagnak át kell mennie, vagy egyszerűen csak ez kényelmesnek tűnt, és igazából jól elvagy a szolgáltatásportok beforwardolásával....

Én mondjuk azt nem értem, hogy aki ebben a szakmában dolgozik, hogy jut eszébe ilyen hülyeség. Vagy ha eszébe is jut (mert épp lelkesen vág bele egy feladatba), hogy nem döbben rá, hogy hülyeség. Ehelyett még vissza is kérdez (már vagy 3x), hogy pontosítsa a csodálatos elképzelését.

( nagysa v | 2015. 07. 21., k – 14:11 )

Szerintem:
apache proxy module

aztán

ServerName teszt.hu
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / http://belső-ip-cím/
ProxyPassReverse / http://belső-ip-cím/

Hátránya, hogy a belső host-on az apache logban a látogató
mindig a szerver lesz.