AIK
Jump to navigation
Jump to search
Overview
This page exists for historical reasons only.
Details
- Public IP: 81.6.2.57
- Interne IP: 172.16.13.57, Subnetz Maske 255.255.224.0
- 172.16.13.57 mit Subnet Mask 255.255.224.0 ist gleich wie 172.16.0.0/19
- es wird jedenfalls angenommen, dass das Haupt-Netzwerk 172.16.0.0 heisst, muss aber nicht so sein
- es ergeben sich daraus folgende 8 m�gliche Subnetze innerhalb von 172.16.0.0:
- 172.16.0.0, von 172.16.0.1 bis 172.16.31.254
- 172.16.32.0, von 172.16.32.1 bis 172.16.63.254
- 172.16.64.0, von 172.16.64.1 bis 172.16.95.254
- 172.16.96.0, von 172.16.96.1 bis 172.16.127.254
- 172.16.128.0, von 172.16.128.1 bis 172.16.159.254
- 172.16.160.0, von 172.16.160.1 bis 172.16.191.254
- 172.16.192.0, von 172.16.192.1 bis 172.16.223.254
- 172.16.224.0, von 172.16.224.1 bis 172.16.255.254
- mit 172.16.13.57 befinde ich mich im 1. der Subnetze
- Bei Problemen mit der Netzwerkanbindung
- Anderen PC mit DHCP an Kabelmodem anschliessen
- z.B. 29.02.2004: moria kriegt IP Adresse 172.16.10.224, 255.255.224.0, Gateway 172.16.10.1, keine DNS Server
- Um Einfl�sse des Switch auszuschalten, sollte ein Hub verwendet werden, oder man schliesst den Server direkt an das Kabelmodem mit einem gekreuzten Kabel
- Um Probleme durch Ueberhitzung auszuschliessen: Strom aller beteiligten Ger�te �ber Nacht unterbrechen
- Um Einfl�sse von Firewall/NAT Regeln auszuschalten, sollte der Rechner ohne iptables Eintr�ge neu gebootet werden
- damit ist zwar kein Zugriff von Rechneren aus dem 192.168.1.0 Netzwerk mehr m�glich, aber das ist f�r diesen Test auch nicht n�tig
- Um Einfl�sse von anderen Prozessen auszuschalten, k�nnen folgende Daemons ausgeschaltet werden
- portsentry (!)
- mysql, mldonkey, setiathome, dhcp3-server, courier-authdaemon, courier-imap, courier-imap-ssl, slapd, apache
- Diagnose
- tethereal -i <outgoing interface> -w capture-file -S
- das bei -i angegebene Interface wird im Promiscuous Mode ge�ffnet
- die Daten werden in das bei -w angegebene File geschrieben. Achtung: das File wird mit Puffer (z.B. 8192 Byte) geschrieben
- die Option -S bewirkt, dass die geschriebenen Daten gleichzeitig live decodiert und auf stdout ausgegeben werden
- um Interface nicht im Promiscuous Mode zu �ffnen: -p
- um keine Namensaufl�sungen vorzunehmen: -n
- um einen Capture Filter anzugeben: -f "filter rule"
- Details siehe man tcpdump
- m�gliche Typ Qualifiers: host, net, port
- m�gliche Direction Qualifiers: src, dst, src or dst, src and dst
- m�gliche Protokoll Qualifiers: ether, ip, tcp, udp, arp, rarp
- weitere Keywords: gateway, broadcast, less, greater, arithmetische Ausdr�cke
- logische Keywords: and, or, not
- host kann mit diesen vorangehenden Keywords erweitert werden: ip host, arp host, rarp host, ip6 host
- z.B. ip host 192.168.1.1
Dies ist gleichwertig wie: ether proto ip and host 192.168.1.1
- port kann mit diesen vorangehenden Keywords erweitert werden: tcp port, udp port
- z.B. tcp src port 21
- proto kann mit den vorangehenden Keywords ip oder ether erweitert werden
- z.B. ip proto icmp
- z.B. ip proto udp or tcp
- da icmp, udp und tcp ebenfalls Schl�sselw�rter sind, m�ssen sie mit \ vorbehandelt werden
- z.B. ether proto ip|arp|atalk|ipx|netbeui
- auch diese Keywords m�ssen mit \ behandelt werden
- ICMP Typen: icmp-echoreply, icmp-unreach, icmp-echo, icmp-sourcequench
- z.b. icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply
- weitere spezielle Beispiele:
- ether broadcast: das Paket ist ein Ethernet Broadcast
- less 512. Ist gleichbedeutend wie: len <= 512
- greater 512. Ist gleichbedeutend wie: len >= 512
- tethereal -r capture-file
- liest das angegebene Capture File und decodiert es auf stdout
- ping: sendet ICMP Echo Eequests
- traceroute: um ICMP Echo Requests zu verwenden, muss je nach Implementation die Option -I verwendet werden (z.B. bei Debian)
Ansonsten werden evt. UDP Pakete verschickt
- Falls im Promiscuous Mode gearbeitet wird, werden auch Pakete gesehen, die vielleicht von der Firewall geschluckt werden
- Schritte
- zuerst sniffen, ob Pakete von ausserhalb hereinkommen (z.B. ARP Broadcasts von 10.0.0.1)
- falls ja: Leitung nach aussen funktioniert generell
- ping auf Hosts, die immer weiter entfernt liegen
- zuerst Kabelmodem intern, dann extern
- dann mein Default Gateway
- dann der "Super" Gateway/Server
- dann ein Internet Host
- sobald auch nur ein ping funktioniert, bedeutet das, dass mein Server nicht grunds�tzlich ICMP blockiert!
- funktioniert ein Ping nicht und ich sehe auch den Echo Reply nicht beim Sniffen im Promiscuous Mode, dann bedeutet das, dass der Reply nicht zu
mir zur�ck geroutet wird
- Ziele f�r ping und traceroute:
- 192.168.100.1 = Kabelmodem
- 10.0.0.98 = Kabelmodem
- 172.16.10.1 = mein Default Gateway
- 10.0.0.1 = "Super" Gateway/Server
- 172.16.250.2 = ??? Ein weiterer Gateway, der sich auf dem Weg ins Internet "hinter" 10.0.0.1 befindet (siehe nachfolgendes traceroute Log)
- 172.16.13.50 = anderer PC, der ebenfalls hinter einem Kabelmodem h�ngt und dessen Verkehr nach dem gleichen NAT Schema wie mein Verkehr abgewickelt wird
(es werden alle Adressen von 172.16.13.50 bis 172.16.13.62 nach dem gleichen NAT Schema behandelt)
- 81.6.2.35 = erster Nameserver
- 193.201.12.53 = www.blick.ch
- 216.239.39.104 = www.google.ch
- Beispiele f�r traceroutes von moria aus (Datum 15.02.2004):
- traceroute to www.blick.ch (193.201.12.53), 30 hops max, 40 byte packets
1 osgiliath (192.168.1.6) 0.738 ms 0.339 ms 0.317 ms
2 10.0.0.1 (10.0.0.1) 8.531 ms 7.397 ms 8.338 ms
3 172.16.250.2 (172.16.250.2) 16.599 ms 11.171 ms 8.718 ms
4 zux006-002-033.adsl.green.ch (81.6.2.33) 12.176 ms 12.828 ms 9.739 ms
5 80.254.161.232 (80.254.161.232) 19.575 ms 19.814 ms 20.161 ms
6 zh1-ipe01-ge01.noc.green.ch (80.254.161.49) 19.438 ms 19.89 ms 20.254 ms
7 zh2-ipe01-ge01.noc.green.ch (80.254.161.59) 20.907 ms 21.427 ms 20.195 ms
8 gi14-0.zur01b04.sunrise.ch (195.141.200.169) 21.383 ms 24.55 ms 21.116 ms
9 * gi0-3.zur14s01.sunrise.ch (193.192.234.207) 320.928 ms 22.016 ms
10 tix-1.mediaways.net (194.42.48.19) 23.438 ms 22.758 ms 22.504 ms
11 rmwc-frnk-de02-pos-2-9.nw.mediaways.net (195.71.158.53) 25.647 ms 100.26 ms 31.719 ms
12 rmwc-frnk-de01-pos-7-0.nw.mediaways.net (195.71.254.105) 96.9 ms 198.113 ms *
13 rmwc-gtso-de02-pos-3-0.nw.mediaways.net (195.71.254.121) 37.512 ms 42.023 ms 36.878 ms
14 195.71.13.76 (195.71.13.76) 33.418 ms 41.675 ms 64.682 ms
15 193.201.12.53 (193.201.12.53) 95.307 ms 33.405 ms 34.455 ms
- traceroute to www.google.akadns.net (66.102.9.99), 30 hops max, 40 byte packets
1 osgiliath (192.168.1.6) 0.664 ms 0.349 ms 0.327 ms
2 10.0.0.1 (10.0.0.1) 7.614 ms 6.771 ms *
3 172.16.250.2 (172.16.250.2) 7.554 ms 8.982 ms 8.927 ms
4 zux006-002-033.adsl.green.ch (81.6.2.33) 75.633 ms 11.649 ms 9.623 ms
5 80.254.161.232 (80.254.161.232) 19.586 ms * 33.164 ms
6 zh1-ipe01-ge01.noc.green.ch (80.254.161.49) 19.464 ms 19.725 ms 20.307 ms
7 zar1-ge-3-0-0.zurichzuh.cw.net (208.175.232.217) 22.556 ms 20.534 ms 21.205 ms
8 ycr1-ge-3-3-0.zurichzuh.cw.net (208.175.232.129) 23.065 ms 23.852 ms 20.281 ms
9 bcr1-so-7-0-0-0.frankfurt.cw.net (166.63.195.201) 27.42 ms 28.591 ms 27.694 ms
10 bcr1.paris.cw.net (208.172.250.61) 34.991 ms 38.892 ms bcr2.thamesside.cw.net (166.63.210.62) 45.091 ms
11 ycr2-so-0-0-0.dublin.cw.net (166.63.209.198) 113.164 ms 62.485 ms 57.784 ms
12 ycr1-so-0-0-0.dublin.cw.net (166.63.163.142) 128.211 ms 56.381 ms 60.555 ms
13 google.dublin.cw.net (208.175.245.94) 55.867 ms 52.358 ms 64.663 ms
14 64.233.174.186 (64.233.174.186) 106.879 ms 50.825 ms 54.743 ms
15 64.233.174.18 (64.233.174.18) 105.816 ms 56.219 ms 60.612 ms
16 * * *
[...]