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@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/
