On 2016-08-15 11:39, Molnar Peter wrote:
Allapot:
A szerverek elerhetoek a nagyvilagbol (ergo jo a portforward a 2.
routeren),
valamint a 192.168.1.x tartomanybol.
Ellenben a 192.168.5.x tartomanybol nem.
Erre lenne szukseg.
Azt irtad, nem latod, miert maradt ki ket hop, a ket publikus IP a
traceroute kimenetbol. Nem irtad, de felteszem, hogy a publikus IP-t
trace-elted, ilyenkor valoszinuleg a kovetkezo tortenik.
1) a 192.168.5 -os PC a default gateway fele kuld egy icmp-t, ha
windows, egy udp-t, ha linux
2) a default gateway a router 1, aminek a dinamikus publikus cime van
3) o valaszol egy icmp redirect-tel, miszerint hagyjal engem beken, a
masik routert kerdezd a 192.168.5 -on (router 2)
4) a PC-d ujrakuldi ugyanazt a kerest router 2-nek
5) aki pedig valaszol is, mint az elso hop (mert az is)
ebben tehat semmi kivetnivalot nem latok, ez pedig a tracerotue
mukodesebol fakadoan van. A traceroute windows eseten icmp, unix eseten
udp (kiveve ha rootkent -I kapcsoloval futtatjak) csomagokat kuld a cel
fele, egytol emelkedo TTL-lel. Mint azt nyilvan te is tudod, a TTL
minden routing hop-on csokken es amikor elerte a nullat, egy ICMP
destination unreachable uzenet erkezik vissza. Erre ugrik ra a
traceroute kliensed es irja ki: ahha, ez volt az IP aki kuldte, o a next
hop.
A kapott informaciok alapjan a fenti szamozott reszben irtam, hogy
szerintem valojaban mi tortenik, az elso ICMP pedig ebben az esetben nem
destination unreachable, hanem redirect. Tehat a kliensed nem ugrik ra.
Az oprendszer viszont raugrik. Igeeen, ne a default gateway fele
menjek? Jo akkor masfele megyek. Ez a lepes a traceroute-nak
lathatatlan, nem reportolja. Amikor pedig az oprendszer a jo iranyba
kuldi ujra a csomagot, az elso router ami eldobja (hiszen a TTL 1 volt,
most lett nulla) pedig maga a cel, a kettes routered.
Egy wireshark igazolhatja, hogy az elmeletem helyes-e, dupla ICMP uzenet
az elso hopig, amibol csak egy relevans.
Ami a NAT elerhetetlenseget mutatja, nem ismerem a telekom felallasat,
fogalmam sincs miert csak ket routerrel lehet ezt megoldani, nyilvan van
egy olyan peremfeltetel, amit nem ismerek a levelbol meg nem derult ki.
Raadasul ha jol latom valaki mas mar ipsec vpn-t lat a ket router kozott
ami nem lehetetlen, de megint csak nem derul ki az ertelme a levelbol,
szamomra nem trivialis a letezese.
Altalanossagban en a kovetkezoket neznem meg:
- publikus vagy privat cimmel cimzed a celt? Nem mindegy, ugyanis bar a
cel vegul ugyanaz lesz, de mas szabalyok vonatkoznak a csomagra: mik
ezek a szabalyok?
- ha privat cimmel, a routing helyes-e? elkepzelheto, hogy a 192.168.1
nem ismert a router 1-nek, igy nem tud redirectet sem kuldeni, neked
kell statikus route bejegyzest felvenni
- ha publikus cimmel, akkor a nat beallitas engedelyezi-e, hogy a
192.168.5 cimmel cimforditas tortenjen? elkepzelheto, hogy nem
Azt mar megnezted, hogy az odairanyu csomag valoszinuleg elvesz, de a
teszted szerintem feluletes. Ha a visszairanyu csomaggal van baj, akkor
a teszted hibas.
Az, hogy egy apache keres megjelenik-e a logokban, azt jelenti, hogy
elotte mar egy TCP handshake lezajlott es felepult a TCP session. Ez
azt jelenti, hogy az oda-vissza kapcsolat helyes.
Az viszont, hogy nem latsz bejegyzest, nem mondja meg, hogy hol a baj.
Lehet van ketiranyu kapcsolat, csak mas cimrol megy vissza a valasz,
mint amire a kliens szamit (peldaul megszolitod 192.168.1 cimmel es
publikus ip-rol jon a valasz).
1) siman a NAT nincs beallitva erre a cimtartomanyra
2) be van allitva, de ACL tiltja a forgalmat
3) NAT be van allitva, ACL nem tiltja, de a valasz csomagok rossz IP
cimre forditodnak
Az, hogy melyik, nem az apache log fogja megmutatni, az apache log mar
csak akkor jon kepbe, ha a TCP handshake rendesen lezajlott. Az, hogy
lezajlik-e oprendszer szinten dol el, az alkalmazas (a webszerver) nem
fog tudomast szerezni rola. A megoldas a wireshark, szerveren inkabb
tcpdump, ebbol fog kiderulni, a handshake melyik csomagja meddig jut el,
arra milyen valasz megy, ha megy es ez utan lehet megmondani, miert nem
mukodik a kapcsolat.
En elorol kezdenem es kihagynam a NATot, lassam, hogy a sima routing
mukodik-e. Itt sajnos, ha a kettes routered szappantarto, akkor eleve
elbuksz, mert ezek route-olni nem tudnak, csak natolni, igy az alapveto
hibakeresest sem biztos, hogy lehetoseged van elkezdeni.
udv
adam
_______________________________________________
Techinfo mailing list
[email protected]
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/
