[Techinfo] erdekes halozat

[ka at mayten.sch.bme.hu]

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