[zorp-hu] Re: [tproxy] tproxy 2.6.10+

[KOVACS Krisztian]

  Szervusz,

2005-06-22, sze keltezéssel 15.11-kor Pásztor Lénárd Zoltán ezt írta:
> Megneztem a linket amit kuldtel. Igy megy is a dolog, persze jobban 
> belegondolva
> sajnos meg sem egeszen jo nekem ez a megoldas, mivel igaz igy a logjaim 
> jok lesznek,
> de dinamikus oldalaknal ahol a site ellenorzi a kliens IP cimet (lekeri 
> az apache-tol, pl $REMOTE_HOST php-ben)
> mindig a proxy cimet kapja viszont.
> 
> Ket megoldas letezik a fejemben:
> 
> 1. apache szinten vajon meg lehet-e oldani, hogy mit adjon vissza? (es 
> akkor ez a headeres hack
> mehet tovabbra is igy)

  Ezt gondolom PHP szinten egy egyszeru search-and-replace-szel lehet
megoldani; a headereket ott is latod. Ennek persze megvan az a hatranya,
hogy a dolog innentol nem teljesen transzparens... A dolog elonye
viszont, hogy kihagysz egy komponenst a rendszeredbol, ami egyebkent
raadasul a kernelben lakozik, plusz problemaforras, stb. (Raadasul amint
latszik, ha sajat kernelt hasznalsz akkor a patcheles is problema.)

> 2. tproxy gondolom. Irtad hogy ha a 01-nat_reservations tema kimarad 
> akkor gyorsan ossze
> tudsz hozni egy patch-et nagyobb verzioszamu kernelhez.
> 
> El tudod mondani mit csinal ez a resze a patch-nek?
> Amugy a lenyeg az, hogy a belso szerver ugy lassa, hogy az eredeti 
> kliens IP-rol jon a csomag.
> Ezt meg lehet oldani a nat reservation nelkuli patch-el?

  Persze. Ilyen HTTP proxyzashoz nem kell a NAT reservations; az csak
bonyolultabb esetekben segit annyit, hogy kisebb esellyel foglalja el
valami mas kapcsolat a Zorp altal hasznalni kivant cimet. (A reszletek
kicsit bonyolultak, ugyhogy itt most nem mennek bele a Netfilter
connection tracking lelkivilagaba.)

> Jelenleg 2.6.12-t hasznalok, de jo a 2.6.11-es verzioval mukodo patch is 
> ha az elobbi nagy szivas.

  Ha egyszer lesz patch 2.6.11-hez, akkor onnan a 2.6.12 mar trivialis.

-- 
 Regards,
  Krisztian Kovacs