[Techinfo] Joomla 1.5 költöztetése újabb rendszerre

[ka at mayten.sch.bme.hu]

Nezzuk sorban - hosszu lesz.

On 09/27/2016 20:30, Fehér Sándor wrote:
> A weblapunk tűzfal mögött portforwarddal volt/lesz megoldva.
> Eddig: sulinet >>>> asus rx router >>>> webserver >>>>> LAN

Ugye csak az abra rossz es a webszerver nem a lan es a router kozott ul? 
  Ugye valojaban azt akartad rajzolni, hogy a webszervern a lanon van?

Ez felvet egyeb kerdeseket (hol a dmz?) de most ezekkel egyelore ne 
foglalkozzunk.

> A probléma ezzel eredetileg is az volt, hogy a LAN -ról nem tudtunk
> kapcsolódni a publikus dns nevünkhöz és a weblap csak úgy működött hogy
> lan ip címet vagy weblap.local kellett beírni.

Ez tulajdonkeppen nem problema.  Mert mi tortenik ugye a csomaggal 
bentrol?  DNS feloldas, kap a nevhez egy publikus IP cimet.  A publikus 
IP cimet megcimzi a belso kliens.  Eljut a routerhez.  A router meg 
tipustol fuggoen:

a) megnatolja a csomagot, mert a nat elobb jon, mint a routing, megnezi 
hova kell kuldeni: nahat, sajat magamnak, de vicces, jo, elkuldom sajat 
magamnak, a 80-as portra, amit rogton be is natolok magamnak a privat 
cimre.  Megerkezik a szerverhez, a forras cim a sajat publikus cimetek, 
a szerver valaszol, az megint megjon a routerhez, nahat, de vicces, 
sajat magamnak visszanatolom es visszakuldom.  Es visszaer a csomag.

b) route-olna a cimet, mert a route dontes elobb jon, mint a nat, 
eszreveszi: nahat en vagyok a cimzett, de mokas, majd be is natolja a 
webszervernek, de a forras cimet erintetlenul hagyja.  A szerver 
megkapja, a forras cim a belso privat cim, arra valaszol is.  A kliensed 
pedig azt latja: nahat, de erdekes, valaszolt nekem valaki akihez nem is 
beszeltem, hisz en a <publikus cim> -rol varom a valaszt, de az a 
<privat cim> -rol jon.  Ezt eldobjuk, mi nem erre varunk.

c) route-olna a cimet, mert a route dontes elobb jon, mint a nat, 
eszreveszi: nahat, en vagyok a cimzett, de mokas.  nembaj, azert 
megnatoljuk a forras cimet is.  varjunk csak: az hogy van, hogy a forras 
is en vagyok meg a cimzett is. aaaa segitseg, inkabb dobjuk el a 
csomagot, biztos tamad valaki.

Hogy nalad melyik tortenik, azt helyesen tcpdump segithet kideriteni, de 
remelem sikerult ravilagitanom, hogy miert nem veszunk szappantartot 
routernek.

Akit konkretan erdekel, hogy pontosan milyen sorrendben milyen muveletek 
tortennek amikor tobb mindent kell eloszor csinalni, a routerenek 
dokumentaciojaban talal errol informaciot.  Peldaul:

http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/6209-5.html

Ebben lathato, hogy peldaul belulrol kifele elobb tortenik route, majd 
policy route, vegul nat (kabe tiz masik dolog mellett).  Mig kivulrol 
befele eppen forditva, elobb van nat, utana route.

Raterve a konkret problemadra, a problema nem egyedi.  A google 
keresoszavak: hairpinning, illetve 'nat order of operation'.  Szamtalan 
talalat lesz.  Annyira, hogy erdemes egy harmadik kereso kifejezest is 
eszben tartani: dns doctoring.  Ezt konkretan a tuzfalak tudjak 
csinalni, ami annyit tesz, hogy a fenti esetben, amennyiben a DNS 
szerver fele a keres es a valasz is athalad a tuzfalon, meghozza azon a 
tuzfalon aki a natolast es port forwardolast csinalja, o felismeri a 
tartalmat.  Rajon, hogy hoppa, itt egy belso kliens akarja elerni a 
belso szervert de kulso IP cimen.  Nyuljunk bele ebbe.  Es szo nelkul a 
DNS valaszba belenyulva kicsereli a DNS altal adott publikus IP cimet 
arra a privatra, amit a sajat konfiguraciojabol nez ki.

Nem csak a cisco eszkozei csinaljak, de legyunk konzisztensek, egy 
leiras errol:

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115753-dns-doctoring-asa-config.html

 > Kerülőmegoldásom: saját statikus dns rekord, ha benntről kéri a kliens
 > lan ip-t ad vissza. >>>> Ez nem túl elegáns :), pl okosteló, laptop
 > elviszed melóból és otthon már ipconfig /flushdns kell!

Azaz mint latod, a sajat favago megoldasod nem is annyira sajat es meg 
kevesbe favago!  A flushdns problemaba en meg nem futottam bele, mivel a 
kliens ugyis mas dhcp szervertol (valoszinuleg) mas cimet fog kapni, 
automatikusan uriti a cache-t.  Kiveve persze, ha otthon is 192.168.4-es 
tartomanyt hasznalsz, akkor a laptop eszre se veszi, hogy valahol mashol 
van.

> $IPT -A POSTROUTING -t nat -o $sulinet -j MASQUERADE
> $IPT -A PREOUTING -t nat -i $sulinet -p tcp --dport 80 -j DNAT
> --to-destination 192.168.4.251:80

ez a ketto tiszta ugy

> $IPT -A PREOUTING -t nat -i $lan -s 192.168.4.0/24 -p tcp --dport 80 -j
> DNAT --to-destination 192.168.4.251:80
>

Ez viszont nekem zavaros.  Ez szerintem a cellal ellentetben azt 
csinalja, hogy _minden_ 80-as portra meno forgalmat atiranyit a sajat 
belso szerveretekre, ugyanis nincs megadva -d, tehat alapertelmezetten 
0/0 lesz.

> Így sajnos nem jó, a tcpdump szerint eljut a szerverhez a tűzfalról a
> csomag és válaszol rá a szerver, de a kliens a választ már nem kapja
> meg. (kliens ebben az esetben azonos subnet-en van a szerverrel.
> A tcpdump szerint, a szerver a default gw-nek küldi a választ a DNAT
> miatt és ott elveszik a csomag.
>

Nem irtad, hogy a szerver milyen forras cimmel latja a beerkezo 
csomagot?  Azt irod, hogy a szerver a routernek kuldi a csomagot, de ezt 
en ketelkedve olvasom.  Ket ok miatt.

1) a PREROUTING lanc elobb kerul kiertekelesre, mint a POSTROUTING, 
tehat a csomag mar akkor tudja, hogy merre kell mennie, mielott valami 
SNAT szaballyal talalkozott volna

2) a PREROUTING eredmenye az, hogy a $lan interfeszeden megy ki a 
csomat, tehat a MASQUERADE a POSTROUTINGban nem jut ervenyre, mivel 
ahhoz -o $sulinet kell, ami ugye nem tortenik meg (a csomag hamarabb 
eliranyitodik a $lan iranyba)

Hangsulyozom, hogy lehet, hogy nalad vannak meg iptables POSTROUTING 
szabalyok, de en ugye csak abbol dolgozom, ami a levelben van.  A 
levelben mas nincs.  Igy tehat a fentiek csak akkor nem igazak, ha az 
iptables szabalyaid kozott van valami mas is, amit trukkosen kihagytal 
es befolyasolja a csomag cimforditasat.  Ami nem lehetetlen, ez a lista 
sajnos nem arrol hires, hogy minden szukseges informacio meg lenne adva.

A kapott informaciokra alapozva, szerintem az az allitasod, hogy a 
szerver a router fele kuldi a csomagot, nem igaz.  Azert, mert a forras 
NAT nem valosul meg, ergo a szerver a valodi, privat cimet latja es 
kozvetlenul valaszol neki, mert a routereden a POSTROUTING lancbol nem 
masoltal be semmit, ami -o $lan -ra lenne ervenyes.

Tehat aszimmetrikus routing lesz, ami onmagaban nem baj, de a router nem 
tud valaszt tovabbitani, mert sosem latja, a kliensed pedig eldobja azt, 
mert o nem a privat cimtol var valaszt, hanem a publikustol, mert azt 
szolitotta meg.  Lasd b) pontot az elejen.

udv
Adam