microsoft.com nem elérhető <megoldva, magyarázat=?>

Microsoft Windows

Nem tudom böngészőbe betölteni a tárgyban jelszett oldalt,
sem a windowsupdate.microsoft.com
sem a live.com
sem a www.update.microsoft.com

Hogy honnan?
Van egy ubuntu 7.10-em, onnan lejön (Firefox, lynx).
Ez a gép egy tvnet adsl-lel megy a netre és osztja a hálót (MASQUARADE).

Az alhálón van egy Pista és egy XP, IE7-tel és Firefox-szal, és ezeken a gépeken minden oldal lejön, kivétel a fenn jelzettek. Ezek timeoutolnak. Mindkettő böngészőben.

Miért?
Merre keressem a hibát?

  • 5182 megtekintés

( synapse | 2007. 12. 26., sze – 12:32 )

host microsoft.com
ping microsoft.com
wget microsoft.com

????

synapse

én@kompakk:~$ host microsoft.com
microsoft.com has address 207.46.197.32
microsoft.com has address 207.46.232.182
microsoft.com mail is handled by 10 mailc.microsoft.com.
microsoft.com mail is handled by 10 maila.microsoft.com.
microsoft.com mail is handled by 10 mailb.microsoft.com.

Az első cim pingethető, a máodik nem.

wget microsoft.com ....
12:34:00 (46.10 KB/s) - "default.aspx" mentve [47018/47018]

(bár ez utóbbi nem meglepő - mint mondtam, a linuxos gépről simán lejönnek ezeke az oldalak.)

van, a windowsos gépekről nslookup-ható a microsoft.com
ping ugyanúgy mint a linuxosról, az egyik pingelhető, a másik nem
a böngészőbe ip-t irva sem jön le az oldal
80 elvileg nincs blokkolva:
XP-ről be tudok telnetelni, majd 400-zal (Bad request) elzavar
Visztát most látok először, telnet nyet.
Putty mind2 windowson eltűnik a p-be ahogy rákattintok az 'Open'-ra

( Huncraft v | 2007. 12. 26., sze – 12:54 )

Tapasztalati kérdés: Véletlenül nem Microsoft által gyártott Nvidia hálókártya drivered van, vagy az nvidia driver mellé adott tűzfal nincs feltéve? => Nekem olyankor volt ez a hiba :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

( Oops | 2007. 12. 26., sze – 13:39 )

Az ubuntu a következő szkriptecskével oszt netet:
#!/bin/bash
IPTABLES=/sbin/iptables

$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES --flush
$IPTABLES --flush -t nat
$IPTABLES --flush -t mangle
$IPTABLES --delete-chain
$IPTABLES --delete-chain -t nat
$IPTABLES --delete-chain -t mangle

$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -s 192.168.168.0/24 -j ACCEPT
$IPTABLES -A FORWARD -s 172.16.38.0/24 -j ACCEPT

$IPTABLES -t nat -A POSTROUTING -o ppp0 -s 192.168.168.0/24 -j MASQUERADE
$IPTABLES -t nat -A POSTROUTING -o ppp0 -s 172.16.38.0/24 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

Ebben tutira nincs hiba..
De mivel, hogy csak a win-es gépeken van a hiba, így én a helyedben ott kezdenék el vizsgálódni.

pl nslookup megy e és jó címet ad e vissza> A windows tűzfal kivételei között nincs e véletlenül felsorolva vmi local blacklisten, vagy más tűzfal beállítás nem vonatkozik e rá?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

( Oops | 2007. 12. 26., sze – 14:11 )

logolni kezdtem a Forward lánc cuccait, külön az esetleg megtagadottakat (nem volt ilyen)

A logrészletben előfprduló IP-k:
207.46.193.254: www.microsoft.com
192.168.168.101: windows Vista-s gép
195.38.96.31: TVNet DNS

Ja, amiz nem mondtamm az IE7 és a Firefox és sokáig (10+ perc) próbálkozik, mielőtt aszondaná, hogy nem megy.

Dec 26 14:00:38 kompakk kernel: [ 7194.189832] FORWARD: IN=eth0 OUT=ppp0 SRC=192.168.168.101 DST=207.46.193.254 LEN=496 TOS=0x00 PREC=0x00 TTL=127 ID=7460 DF PROTO=TCP SPT=49415 DPT=80 WINDOW=63733 RES=0x00 ACK PSH URGP=0

Dec 26 14:00:38 kompakk kernel: [ 7194.847236] FORWARD: IN=eth0 OUT=ppp0 SRC=192.168.168.101 DST=207.46.193.254 LEN=496 TOS=0x00 PREC=0x00 TTL=127 ID=7461 DF PROTO=TCP SPT=49415 DPT=80 WINDOW=63733 RES=0x00 ACK PSH URGP=0

Dec 26 14:00:39 kompakk kernel: [ 7195.119045] FORWARD: IN=ppp0 OUT=eth0 SRC=207.46.193.254 DST=192.168.168.101 LEN=40 TOS=0x00 PREC=0x00 TTL=234 ID=49977 PROTO=TCP SPT=80 DPT=49415 WINDOW=62915 RES=0x00 ACK URGP=0

Dec 26 14:01:16 kompakk kernel: [ 7232.232527] FORWARD: IN=eth0 OUT=ppp0 SRC=192.168.168.101 DST=195.38.96.31 LEN=71 TOS=0x00 PREC=0x00 TTL=127 ID=7462 PROTO=UDP SPT=49585 DPT=53 LEN=51

Dec 26 14:01:16 kompakk kernel: [ 7232.296478] FORWARD: IN=ppp0 OUT=eth0 SRC=195.38.96.31 DST=192.168.168.101 LEN=169 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=53 DPT=49585 LEN=149

Dec 26 14:01:16 kompakk kernel: [ 7232.300037] FORWARD: IN=eth0 OUT=ppp0 SRC=192.168.168.101 DST=195.38.96.31 LEN=63 TOS=0x00 PREC=0x00 TTL=127 ID=7463 PROTO=UDP SPT=49586 DPT=53 LEN=43

Dec 26 14:01:16 kompakk kernel: [ 7232.367743] FORWARD: IN=ppp0 OUT=eth0 SRC=195.38.96.31 DST=192.168.168.101 LEN=485 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=53 DPT=49586 LEN=465

Dec 26 14:03:38 kompakk kernel: [ 7374.469263] FORWARD: IN=ppp0 OUT=eth0 SRC=207.46.19.254 DST=192.168.168.106 LEN=40 TOS=0x00 PREC=0x00 TTL=232 ID=56388 PROTO=TCP SPT=80 DPT=1091 WINDOW=9300 RES=0x00 RST URGP=0

Dec 26 14:03:38 kompakk kernel: [ 7374.471120] FORWARD: IN=eth0 OUT=ppp0 SRC=192.168.168.106 DST=207.46.19.254 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=1201 DF PROTO=TCP SPT=1091 DPT=80 WINDOW=65535 RES=0x00 ACK URGP=0

Dec 26 14:04:47 kompakk kernel: [ 7443.609208] FORWARD: IN=ppp0 OUT=eth0 SRC=207.46.193.254 DST=192.168.168.101 LEN=40 TOS=0x00 PREC=0x00 TTL=234 ID=65380 PROTO=TCP SPT=80 DPT=49415 WINDOW=9300 RES=0x00 RST URGP=0

Dec 26 14:04:47 kompakk kernel: [ 7443.609581] FORWARD: IN=eth0 OUT=ppp0 SRC=192.168.168.101 DST=207.46.193.254 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=7464 DF PROTO=TCP SPT=49415 DPT=80 WINDOW=63733 RES=0x00 ACK URGP=0

-----------------------
a módosított szkript:
#!/bin/bash
IPTABLES=/sbin/iptables

$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES --flush
$IPTABLES --flush -t nat
$IPTABLES --flush -t mangle
$IPTABLES --delete-chain
$IPTABLES --delete-chain -t nat
$IPTABLES --delete-chain -t mangle

$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -j LOG --log-level debug --log-prefix "FORWARD: "
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -s 192.168.168.0/24 -j ACCEPT
$IPTABLES -A FORWARD -s 172.16.38.0/24 -j ACCEPT
$IPTABLES -A FORWARD -j LOG --log-level debug --log-prefix "FORW_MEGTAGADVA: "

$IPTABLES -t nat -A POSTROUTING -o ppp0 -s 192.168.168.0/24 -j MASQUERADE
$IPTABLES -t nat -A POSTROUTING -o ppp0 -s 172.16.38.0/24 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

( Oops | 2007. 12. 26., sze – 14:54 )

tettem wget-et a vista-ra is, és:

C:\Program Files\GnuWin32\bin>wget.exe microsoft.com
--14:30:00-- http://microsoft.com/
=> `index.html'
IP keresés microsoft.com... 207.46.232.182, 207.46.197.32
Connecting to microsoft.com|207.46.232.182|:80... kapcsolódva.
HTTP kérés elküldve, várom a választ... 301 Moved Permanently
Hely: http://www.microsoft.com [következik]
--14:30:01-- http://www.microsoft.com/
=> `index.html'
IP keresés www.microsoft.com... 207.46.192.254, 207.46.193.254, 207.46.19.190, .
..
Connecting to www.microsoft.com|207.46.192.254|:80... kapcsolódva.
HTTP kérés elküldve, várom a választ... 302 Found
Hely: /en/us/default.aspx [következik]
--14:30:02-- http://www.microsoft.com/en/us/default.aspx
=> `default.aspx'
Reusing existing connection to www.microsoft.com:80.
HTTP kérés elküldve, várom a választ...

és itt várunk, immáron percek óta...
HEELLLPPPP....

szerk: eltelt 13 perc. még mindig vár

szerk2: új fejlemény

HTTP kérés elküldve, várom a választ... Olvasási hiba (Connection reset by peer)
a fejlécben.
Újrapróbálom.

--14:54:02-- http://www.microsoft.com/en/us/default.aspx
(próba: 3) => `default.aspx'
Connecting to www.microsoft.com|207.46.19.190|:80... kapcsolódva.
HTTP kérés elküldve, várom a választ...

( Oops | 2007. 12. 26., sze – 15:06 )

a megoldás a klasszikus mtu=1492 az ubuntu ppp konfigjában

valaki el tudná magyarázni, hogy miért ez a megoláds?
másképp föltév a kérdést:
miért zavarta az mtu beállítás hiánya csak az alhűlón lévő windowsokat, amikor elvileg nekik ez csak egy ethernet?

Baratom most aztan megszopattad magad rendesen.

ICMP-t alapbol blokkolod. Hogyan is mukodik az MTU path discovery?

http://en.wikipedia.org/wiki/Maximum_transmission_unit
http://en.wikipedia.org/wiki/Path_MTU_discovery

Nem esett le amig nem agyaltam ki, hogy miert megy a tuzfalrol de nem a belso LAN-odrol a dolog.

Erdekes, hogy ha mas oldalak mukodnek, csak a microfose nem, akkor miert?
Szerintem azert, mert a winupdate valszeg beallitja modszeresen a DF bitet(don't fragment) es a tobbi pedig nem. Ezert a sima kapcsolatok packetjeit szetfragmentalja az ubi (eleg baj), de igy belefernek a kissebb mtu-ba, es mukodik. A winupdate meg (jo robosztus microsoft termek leven) hulye modon beallitja a DF-et, erre jon az ICMP reply, hogy "Fragmentation Needed". De ezt te persze nem engeded be, szoval senkinek semmi eselye nincs rajonni, hogy mi a fasz tortent a csomaggal.

Ennyi informaciobol ennyit tudok kihozni. Ami meg nem tiszta, hogy a live.com miert nem megy. Ezt tenyleg nem ertem, az is akar telepiteni? Nem ertem. :)
DIFFERENCIALDIAGNOZIST! :D

Nagyon surgosen engedelyezd az ICMP-t, mert AZERT VAN! SEMMI ERTELME TILTANI!

(ezen mindig felbaszodom, mert teljesen baromsag tiltani de rengetegen csinaljak. vki mondja mar el, hogy miert?)

synapse

EDIT: Ja, es bizonyara. Marmint tudja.

Ez kurvanagy baromsag, egy gepet nem lehet icmp-flood-al megfektetni pl 100Mbit-en. a cpu eros joszag. Viszont ha annyit kuld, hogy elveszi a savot, akkor nincs mit tenni. Es ez fuggetlen attol, hogy tiltod-e, mert max annyit ersz vele, hogy nem dolgozod fel.

Illetve feldolgozod /iptables/ es mire elballagsz a match-elo lancig, addig lehet, hogy tobb cpu idodbe kerul, mintha felparse-oltad volna a packetet

synapse

Ping of Death.
Minel elobb (alacsonyabb szinten, kevesebb munkaval) szabadul meg a
rendszer az abszolut folosleges tevekeysegtol,
mint pl. ping csomag feldolgozasa - netan fragmentek gyujtogetese :(,
annal kevesebb eselye lesz tevedni, mivel kevesebbet dolgozik.

Rovidem, ami folosleges a rendszer mukodesehez az ne legyen utban.
KISS

Obscurity? Talan inkabb a magamutogatas mellozese.
Sarkitva - de csak kicsit: Nem erzem kotelessegemnek a scriptkiddik
kiszolgalasat whitebox audithoz szukseges dokumentacioval.

Nagyobb tuzfal eseten a szabalylancokat mire vegignezed, addigra tobb cpu idot pazarolsz el, mintha megnezned, hogy valid-e a packet es hogy hozzad tartozik-e.

A fragmentek gyujtogetese szivas, de az ellen meg nem tudsz mit csinalni. Mindenkepp ossze kell rakni, hogy feldolgozhato legyen.

synapse

Nagyobb tuzfal eseten a szabalylancokat mire vegignezed, addigra tobb cpu idot pazarolsz el,

Mivel a tuzfal nem csomagszuro, igy lehetoleg 2-3 retegben kidobom ami nem hozzam tartozik.
Igy az igazan draga 7. retegben csak azzal kell dolgoznom ami _nekem_ fontos.

mintha megnezned, hogy valid-e a packet es hogy hozzad tartozik-e.

Nos az ICMP/ping nem hozzam tartozik. Ha a kerdezonek fontos vagyok szolitson meg
alkalmazas retegben - ertelmes kerdessel - es valaszolok neki. Ne szimatoljon.

A fragmentek gyujtogetese szivas, de az ellen meg nem tudsz mit csinalni.
Mindenkepp ossze kell rakni, hogy feldolgozhato legyen.

Mivel a fejlec az 1. csomagban jon, igy ha azt kidobom - mert nem hozzam tartozik,
amibe a ping is beletartozik az ertelmezesem szerint - a tobbi darabot azert fogom eldobni,
mert nincs eleje ;)

"Mivel a tuzfal nem csomagszuro, igy lehetoleg 2-3 retegben kidobom ami nem hozzam tartozik. Igy az igazan draga 7. retegben csak azzal kell dolgoznom ami _nekem_ fontos."

Aztakurva. Amellett, hogy nem tudom mirol beszelsz, sztem te sem tudod. Az iptables csomagszuro. Az ICMP az layer 3, az egy speci ip packet. Nem is mehetne feljebb. Hidd el, nem fognak vele webserver-t dosolni.

"Nos az ICMP/ping nem hozzam tartozik. Ha a kerdezonek fontos vagyok szolitson meg alkalmazas retegben - ertelmes kerdessel - es valaszolok neki. Ne szimatoljon."

Rengeteg alkalmazas hasznal icmp echo-t annak kideritesere, hogy elsz-e. Emellett hozzad tartozik, mert van IP cimed. Ha valakinek fontos vagy, akkor eselyes hogy meg ping-el elotte (hogy lassa, elsz-e). Nem szimatol, draga gyermekem, hanem informatikaban EZ A MODJA, nem connect-elhetsz csak ugy barhova. Mert az mar tenyleg udvariatlansag. Nem veletlen talaltak ki.

EDIT:
"Mivel a fejlec az 1. csomagban jon, igy ha azt kidobom - mert nem hozzam tartozik,
amibe a ping is beletartozik az ertelmezesem szerint - a tobbi darabot azert fogom eldobni,
mert nincs eleje ;)"

Igen, ezt megteheted osszerakas nelkul is, ha belefert az egesz header. De egy ip csomag ujraillesztese utan lehet csak megnezni, hogy valid-e a csomag. Kovetkezeskepp, ha egy darab hianyzik, akkor az egeszet lehet ujrakuldeni. El tudok kepzelni helyzetet, ahol ezzel foglaljak le a cpu-t nagyobb mertekben, de meg igy sem jelentos. Amit meg most leirtal, abbol latszik, hogy nagyon erosen hianyos a tudasod ilyen szinten. Ennek olvass utana.

PHP-t programozol ugye?

synapse

Aztakurva. Amellett, hogy nem tudom mirol beszelsz, sztem te sem tudod.

Arrol, hogy minden nem odavalot lehetoleg az elso ponton amikor kiderul rola, hogy nem odavalo, rogton kidobok.
Amelyik csomagrol kiderul, hogy szamomra nem kivanatos az rogton repul. Ha ez a 3. reteg akkor ott.
Ami pedig feljut a 7. retegig, azt sajnos az alkalmazasproxy is kenytelen atcsocsalni.

De egy ip csomag ujraillesztese utan lehet csak megnezni, hogy valid-e a csomag. Kovetkezeskepp, ha egy darab hianyzik, akkor az egeszet lehet ujrakuldeni.

IP csomag eseteben lehet nem erdekel, hogy valid -e.
Nem minden IP statuszos es var valaszt.
A tuzfalak jellegzetessege pedig, hogy nem valaszolnak funek-fanak. Esetleg kuldenek egy RST-t,
vagy eppen hallgatnak a timeoutig...

PHP-t programozol ugye?

Ezert lehet megmosolyognak.

Ne felejtsuk el a kerdes feltevo tuzfalrol - hatarvedelmi eszkozrol - beszelt.
Vagy csak en ertelmeztem az iptables scriptet egy vedelmi megoldasnak. Bar DROP policyvel indult.
Akkor en kerek elnezest.

Figyelmesebben olvasva a 256 (tobbnyire nem is definialt:o) tipusabol
cca. 5 boven eleg a(z ipv4) halozat helyes mukodesehez.
A tobbi folosleges, s a szuksegeseknek nem reszhalmaza a 0/8.

Ha mar vedelmi eszkozrol beszelunk, ne engedelyezzuk a szuksegtelen/karos
tipusokat az "engedelyezd gyorsan az ICMP-t" felszolitas szerint.
ICMP kell. De csak szurve, nem globalisan.

Szoval ICMP kell, de...

Ebbol olvastad, hogy az ICMP folosleges? ;-P