155 lines
4.6 KiB
Markdown
155 lines
4.6 KiB
Markdown
# Internetworking
|
|
> 
|
|
|
|
## MAC und IP-Adressen im Heimatnetzwerk
|
|
|
|
|
|
**Bleiben MAC und IP-Adresse immer gleich?**
|
|
- MAC-Adresse
|
|
- gelten nur im LAN
|
|
- IP-Adresse
|
|
- muss unverändert festbleiben
|
|
|
|
## MAC-Adressierung
|
|
### Beispiel Ethernet-Header
|
|
|
|
|
|
### Beispiel WLAN-Header
|
|
|
|
- nicht mehr nur Quell- und Zieladresse
|
|
- gezwungener Nachrichtenweg über den Router
|
|
|
|
|
|
## Übersicht Network-Layer
|
|
> 
|
|
|
|
### IP und ICMP
|
|
- **Eigenschaften**
|
|
- IP
|
|
- stellt Header im Network Layer zur Verfügung
|
|
- einfache Spezifikation auf beiden Seiten
|
|
- einziges Problem: Fragmentierung von IP-Paketen
|
|
- ICMP
|
|
- Fehlermeldungen und Test des Netzwerks
|
|
- Zwischen Host/Router und Router
|
|
- Fehler werden verursacht durch
|
|
- fehlerhafte IP-Pakete
|
|
- "Nichterreichbarkeit" von Netzen, Hosts, Routern, Diensten
|
|
- Kein Client von L3, sondern von IP
|
|
|
|
#### Internet Protocol V4
|
|
- realisiert verbindungslose Kommunikation auf L3
|
|
- bietet Hardware-unabhängiges Paketformat
|
|
- 
|
|
|
|
##### IPv4 Adressierung
|
|
|
|
- Netz
|
|
- _bspw. anderes Netz für MK/FBI_
|
|
- je feiner man die trennt, desto besser ist Performance, Sicherheit
|
|
- Host
|
|
- Endgerät
|
|
- braucht eine individuelle IP-Adresse
|
|
|
|
##### IPv4 Lebenszeit
|
|
- beim Routen durch vermaschte Netze könnten Datagramme ziellos unendlich lang kreisen
|
|
- Ressourcen werden vergeudet
|
|
> **Lösung: TTL-Feld**
|
|
>
|
|
> Jeder Router reduziert TTL um `1`,
|
|
> bei Erreichen von `0` wird Paket gelöscht
|
|
|
|
###### Subnetting
|
|
- gleich großer Host/Netz Anteil
|
|
- Falls man vom einen mehr braucht → umrechnen
|
|
|
|
#### ICMP
|
|
|
|
- Falls IP Fehler bei Zustellung hat, ICMP zur Benachrichtigung des Senders nutzen
|
|
- Destination Unreachable
|
|
- Fragmentation Needed and DF set
|
|
- _Fragmentierung benötigt, aber nicht erlaubt_
|
|
- Time To Live Exceeded
|
|
- Source Quench
|
|
- _Host kann Datagramme nicht so schnell verarbeiten, wie diese vom Netzwerk eintreffen_
|
|
|
|
**Eigenschaften**
|
|
- ICMP-Nachrichten als Nutzdaten in IP-Paketen
|
|
- enthält
|
|
- Typ
|
|
- 
|
|
- Code
|
|
- ggf. erste 8 Byte des IP-Pakets, das die Fehlermeldung verursacht hat
|
|
- wird direkt von `Ping` und `Traceroute` verwendet
|
|
|
|
##### ICMP: Traceroute
|
|
- Sender schickt IP-Paket mit TTL=1
|
|
- 1. Router sendet ICMP zurück
|
|
- Sender schickt IP-Paket mit TTL=2
|
|
- 2. Router sendet ICMP zurück
|
|
- ...
|
|
|
|
|
|
##### ICMP-Flooding-Angriff
|
|
- Angreifer überflutet Zielgerät mit ICMP-Echo-Request-Paketen
|
|
- Zielgerät beantwortet alle
|
|
- verbraucht Ressourcen
|
|
|
|
##### ICMP Smurf-Angriff
|
|
- Angreifer schickt ICMP-Paket mit gefälschter Quell-IP-Adresse
|
|
- Netzwerk antwortet an gefälschte IP-Adresse
|
|
- → DDoS-Angriff auf OSI-Schicht 3
|
|
|
|
|
|
|
|
|
|
|
|
## Einfaches Internetwork als Beispiel
|
|
|
|
- von H1 aus zu H8
|
|
- R1 packt es aus, schaut wohin, packt es ein und weiter
|
|
- R2 packt es aus, schaut wohin, packt es ein und weiter
|
|
- R3 packt es aus, schaut wohin, packt es ein und weiter
|
|
|
|
|
|
- PPP hat weniger max. Payload als ETH
|
|
- IP muss fragmentieren in kleinere Pakete
|
|
|
|
- Zwei wichtige Punkte
|
|
- Jedes Fragment ist ein in sich abgeschlossenes IP-Diagramm
|
|
- Übertragung unabhängig von anderen Fragmenten über eine Reihe physikalischer Netzwerke
|
|
- Jedes IP-Diagramm wird für jedes zu durchquerendes physikalische Netzwerk in ein entsprechendes Frame gekapselt
|
|
|
|
|
|
### Laptop and DevBoard communication within LAN
|
|
#### Step 0: Überblick
|
|
|
|
|
|
#### Step 1: Open the Webbrowser and Enter IP Address for the Development Board
|
|
#### Step 2: PC Generates and Transmits a Frame
|
|
|
|
|
|
#### Step 3: Frame is Forwarded through the Switch
|
|
|
|
- falls nicht bekannt an welchem Port die richtige MAC-Adresse hängt
|
|
- an alle (bis auf Sender-Port, da ist MAC-Adresse ja bekannt) rausschicken
|
|
|
|
#### Step 4: Frame arrives at the Development Board and is forwarded to the Webserver
|
|
|
|
- auf jedem Layer überprüfen ob an richtiger Stelle
|
|
- Layer 2: MAC richtig?
|
|
- Layer 3: IP richtig?
|
|
- Layer 4: PortNumber running auf dem device?
|
|
|
|
#### Step 5: Webserver on DevBoard generates Frame and sends the page to the pc
|
|
|
|
|
|
#### Step 6: Step 3 with new frame
|
|
- Frame kommt am Switch an
|
|
- Switch schaut, ob er die MAC kennt
|
|
- Switch sendet weiter an PC (Port 3)
|
|
- PC öffnet frame und schaut, ob er für ihn ist
|
|
- PC öffnet Packet und schaut, obs passt
|
|
- PC öffnet Message
|
|
|