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

2016. Sze. 27., K, 22:25:18 CEST

Köszönöm a válaszod!

$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.
Ellenőriztem a sort a szerveren és nem "s" hanem "d" ezt elnéztem.
Ha úgy lenne ahogy írtam, akkor a net sem működne :)
Így van helyesen:
$IPT -A PREOUTING -t nat -i $lan -d 192.168.4.251/32 -p tcp --dport 80 
-j DNAT --to-destination 192.168.4.251:80

Amúgy maga a megoldás az otthoni tűzfalamnak a másolása és konvertálása 
mert otthon van egy freepbx szerverem (asterix).
Ezt a szervert otthonról is elérem a public dns névvel és bárhonnan 
internetről is tudok voipon telefonálni.
Annyi a különbség a két rendszer között, hogy otthon mikrotik 
routerboard van.
A szerver pedig egy proxmox és azon fut a freepbx.
Röviden mikrotikkel megtudtam csinálni és iptables-en nem akar menni.

Futok vele még egy kört, értelmezem a leírtakat. :)
Köszönöm!

2016. 09. 27. 21:59 keltezéssel, ka at mayten.sch.bme.hu írta:
> 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
> _______________________________________________
> Techinfo mailing list
> Techinfo at lista.sulinet.hu
> Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo
> Illemtan: http://www.szag.hu/illemtan.html
> Ügyfélszolgálat FAQ: http://sulinet.niif.hu/