MarcusBe

Eine Fritzbox als Beispiel für das Verständnis von Firewalls zu erlernen, ist nicht gerade die beste Gerät. Nutze da lieber zum testen  als virtuelle  Maschinen pfsense oder jegliche *sense Ableger. Oder von Enterprise-Ablegern kann man auch SophosHome nutzen - probiere es aus.
In deinem Video liest du die Tabelle falsch. Der angegebene Port 80 bei 2:52 ist ein Ziel-Port, kein Quellport.
Der Quellport wird irgendein nicht-Standart Port sein, bspw. 50789.
Ich übersetze dir mal die erste Zeile im Video.
Zustand: Erlauben
Quell-IP: 162.213.214.140
Quell-Port: any ( 49152–65535 )
Protokoll: TCP
Ziel-IP: any (jegliche IP-Adresse ist damit gemeint)
ZIel-Port: 80
(Firewall-Regel für den Rückweg ist hier nicht zu bauen, wenn SPI zum Einsatz kommt)
 
**Off Topic ON **
Quellports im Arbeitsleben sind mit Firewalls eher uninteressant, da die meisten Firewalls das Prinzip 'Stateful Packet Inspection' (SPI) verwenden. Firewalls ohne SPI sind in der Handhabung dann wirklich so, dass du Firewallregeln in BEIDE Richtungen erstellen musst.
Bei einem groẞen mittelständischen Kunden können ohne Probleme ca. 100 Firewall-Regel aufgebaut sein, je nach Vorgaben.
Ohne SPI wäre die Anzahl Faktor x2, also ca. 200 Firewall-Regel.
** Off Topic OFF**

Hallo,
um was für eine Firewall handelt es sich? Statefull? Falls ja, dann brauchst du eingehende Regeln nicht zu machen, da die Firewall bestehende Verbindungen automatisch erkennt.
 
Nein, das ist falsch. Das wäre nur richtig, wenn auf dem Host mit der IP 192.168.12.18 ein Webserver laufen würde und du diesen von extern erreichbar machen möchtest. Du möchtest aber lediglich, dass der Host externe Webseiten aufrufen kann. Im Falle von Stateless Firewalls würde ich dir an dieser Stelle auch empfehlen den TCP Flag ACK zu setzen, falls dies die Firewall unterstützt.

Grundsätzlich gilt: wenn ein Server einen Dienst bereitstellt, dann benutzt er einen Port aus dem Well Known Bereich z.B. Port 80 für HTTP. Clients nutzen für Requests grundsätzlich nur Ports aus dem dynamischen Portbereich. Das ist notwendig z.B. wenn du mit deinen Browser verschiedene Requests zu unterschiedlichen Webservern gleichzeitig durchführen möchtest.


 

Nein. Nun sind sowohl die Regel für den eingehenden als auch für den ausgehenden Verkehr falsch!
Überlege dir erstmals was du überhaupt machen möchtest. Du hast einen Client, der auf einen Webserver zugreifen möchte. Der Webserver bietet seinen Dienst auf Port 80 an, d.h. für den ausgehenden Verkehr brauchst du eine Regel mit Zielport 80. Der Client selbst wählt seinen Port eigenständig aus dem dynamischen Portbereich aus. Nur dadurch ist der Client in der Lage mit mehreren Webservern gleichzeitig zu kommunizieren. Als Quellport muss daher der dynamische Portbereich genannt werden. (49152-65535)
Jetzt kann der Client schon mal eine Verbindung zum Webserver herstellen. Der Webserver möchte nun den Client antworten. Dafür braucht es nun bei einer Stateless Firewall eine eigene eingehende Regel, d.h. der Quellport ist der Port 80 vom Webserver. Der Zielport ist der Port, den der Client für die Verbindung benutzt hat. Da dieser durch den Client selbstständig aus dem dynamischen Portbereich ausgewählt wird, musst du als Quellport den dynamischen Portbereich angeben. Bei der eingehenden Regel wäre noch optional aber sehr sinnvoll die Angabe eines TCP Flags (ACK) notwendig, damit die Firewall wirklich nur bestehende Verbindungen durchlässt.

Ich hoffe diese Erklärung ist nun verständlicher.

Ja. Nun sieht das gut aus.

Dann überlege doch einmal, ob das Problem ohne die Nutzung eines Accesspoints überhaupt zu einem Hidden Station Problem werden kann und wie es sich davon unterscheidet, wenn sich zwei Geräte nicht erreichen können.
Anhand des Scnaubildes auf der verlinkten Seite von Elektrokompendium ist das Problem doch gut zu erkennen. Beider erreich den AP, aber keinen von beiden den anderen, so dass diese die Kanalbelegung selbst nicht feststellen können, außer, dass eben vom AP nichts zurückkommt, da sich bei diesen die Sendungen überlagern.

was isn ne SAT/SAT-Tabelle? switch address table? Wie auch immer: Die genaue Tabellenstruktur und Vorgehensweise ist einfach implementierungsabhängig.
Normalerweise hat ein L3-Switch eine Tabelle, die next hops in MAC-Adressen auflöst. Diese kann entweder statisch gesetzte Einträge enthalten oder eben durch ankommenden Traffic lernen, indem sie die src mac und den ingress port ankommender Frames speichert. Wird ein neuer next hop angeschlossen, reicht ein einzelner Frame, um die neue MAC-Adresse zu lernen. Fehlende Einträge sollten also kaum vorkommen, aber wenn, dann wäre die richtige Entscheidung wohl, den betroffenen Frame zu droppen. D.h. es gibt eine Forwardingtabelle, die z.B. IP-Adressen in next hops übersetzt, und eine kleine next-hop-Tabelle, anhand der dann rausgesucht wird, welche dst mac in den Frame geschrieben werden soll. Mit anderen Worten: Was der Switch benötigt, ist eigentlich nicht die Auflösung von L3- nach L2-Adressen (aka ARP-Tabelle), sondern von Ports nach L2-Adressen. Wobei die meisten ARP-Tabellen diese Info auch enthalten.
Bei einem L2-Switch werden src und dst mac im Frame nicht ersetzt, d.h. der Switch braucht fürs Forwarding gar keine Infos über MAC-Adressen von next hops, sondern muss nur wissen, an welchem Port er den Frame ausgeben soll.
Wie die Forwardingtabellen erstellt werden, ist eine andere Frage (statisch gesetzt bzw. über ein Routingprotokoll + evtll andere Hilfsprotokolle).