2010.09.08. 15:54 keltezéssel, Hegedüs Ervin írta:
>>
>> Nem nagyon ertelek
> konkrétan mit?
>

Az egeszet kavarast, pl minek kell ip cima http-ben, nem lehetne oda is 
dns name-t irni, stb...

>> (plane, hogy a kernel nem szeparalja rendesen az
>> alias interfacek forgalmat),
> a lo interface-t érted alias if alatt? ha nem, hogy jön ide az
> alias if?
>

Az az 1.2.3.4 altalaban virtualis interface cime szokott lenni, akkro 
tevedtem.

>> de miert is nem hasznalsz valami proxyt
>> befele? A squid is tud accelerator lenni, apache/lighttpd/nginx mind tud
>> ilyet.
>
> ez mit változtatna a felálláson?
>

Manipulalhatja a http forgalmat, ha mashogy nem, faragni kell egy 
redirektort, ami atirja a cimet, par perc alatt megoldhato.

> Attól még a Squid a kliens által kért 1.2.3.4-re akarna
> kapcsolódni, konkrétan én ezt látom problémának (tehát h az
> alkalmazás a saját hoszt egyik interface-re akar kapcsolódni, ami
> egyébként DNAT szabály szerint egy másik IP-re megy - vagyis hogy
> lehet lo interfacen egyébként nem lo IP címmel rendelkező
> csomagoknak megmondani, hogy a POSTROUTING-ban levő szabályt
> légyszi' vegyék figyelembe)

Ez mar tobbszor emlegettem a listan, de nem lehet elegszer ismetelni: az 
netfilterben csak a prerouting chainekben lehet olyan szabalyt irni, ami 
a destination interface-en valtoztat, a routeing (ami nem ip routeing, 
tobbek kozott az is itt dol el, hogy melyik lesz az output interface) 
utan mar nem.

>
>
> Én azt javasoltam, h a vegyünk fel egy új rekordot az adott
> zónába, a weblapon írják át az IP hivatkozást DNS névre, és a
> Squid-nek megmondom h az az új A rekord az 5.6.7.8-ra mutat.
>

Nagyjabol, a korrekt megoldas termeszetesen a split-dns, ahol az 
internal dns lefedi az external dnst is, csak a privat ip cimekket ad 
vissza, es termeszetesen http linkben nem hasznaltok ip cimet.

> (de ehhez jelenleg 300 felett jár a felhívott egyének száma, és
> perpill senki nem érzi magát illetékesnek)
>
Jo kis helyen dolgozol :)
_________________________________________________
linux lista      -      [email protected]
http://mlf2.linux.rulez.org/mailman/listinfo/linux

válasz