thrawnx schrieb:
Mitnichten.
Wenn du mich schon zitierst, dann möchte ich dich bitten, das Zitat nochmal sorgfältig zu lesen und dabei insbesondere auf so unwichtige Begriffe wie
bedingt, wenn, kann und
lästig zu achten. Diese beziehen sich nämlich auf die Einschränkungen der Lösung, die ich angesprochen habe und auch deine Argumente betreffen.
Ich kann aber gerne noch etwas ins Detail gehen, wenn du willst.
thrawnx schrieb:
1. kann man die IPs der näheren Twitch Server problemlos per netstat rausfinden
Jein. Du kannst vielleicht die IPs herausfinden, zu denen
aktuell eine Verbindung hergestellt wird, aber keineswegs alle. Besser gesagt: Du weißt nicht ob da evtl. noch andere Server mit im Spiel sind, die eben während deiner Beobachtung der Verbindung via netstat nicht aufgetaucht sind. Ein Unternehmen kann jederzeit neue Server bereitstellen, bestehende Server in ein anderes Rechenzentrum umziehen oder gar komplett abschalten. Es kann also durchaus sein, dass die ermittelten IP-Adressen irgendwann schlicht und ergreifend obsolet sind, man erneut nach IPs suchen muss und der Kreis von vorne beginnt.
thrawnx schrieb:
2. man googled welche IP Ranges Twitch hat und added sie mit Wildcards.
Zum einen gibt es in der Routing-Tabelle keine Wildcards. Ich vermute aber du meinst damit eigentlich Subnetze oder von mir aus auch "IP Ranges", wenn du es denn so ausdrücken willst. Das setzt aber voraus, dass die Twitch-IPs auch wirklich in einem (oder mehreren) Subnetzen liegen und nicht quer durch den IP-Bereich des Rechenzentrums oder gar mehrerer Rechenzentren verteilt sind.
Google ist da auch nur
bedingt eine zuverlässige Quelle, weil Infos aus öffentlichen Foren oder generell von nicht-mit-Twitch-assoziierten Seiten nicht selten auf dieselbe Art erlangt wurden wie du es eben mit netstat tun würdest. Solange die Quelle also nicht direkt von Twitch stammt - zB in den FAQ oder den Support-Seiten -
kann auch diese IP-Liste unvollständig sein oder sich jederzeit ändern.
Meine Aussage, dass das Routing nach Ziel-IPs - Windows kann nun mal nix anderes, selbst Windows Server nicht - in solchen Fällen nur
unter bestimmten Voraussetzungen für diesen Zweck geeignet ist, bleibt daher bestehen. Auch fortgeschrittene Routing-Techniken via PBR sind kein Garant dafür, dass es funktioniert. Es steht und fällt damit, dass man den Traffic zuverlässig und eindeutig identifizieren können muss. Das
kann die Ziel-IP sein, aber auch der Quell- und/oder der Ziel-Port. Deswegen sind einige Dienste auch innerhalb einer Firewall nur schwierig zu blocken, wenn Standard-Ports verwendet werden (zB tcp 80) und zudem ein weltweites Netz an verteilten Servern, deren Liste nicht öffentlich bekannt ist, genutzt wird.
thrawnx schrieb:
Das lässt sich also durchaus über die Windows Routing Tabelle realisieren
Dazu zitiere ich mich mal selbst und markiere die entscheidende Stelle:
Raijin schrieb:
Über die Routing-Tabelle in Windows wie oben empfohlen wurde lässt sich das nur bedingt realisieren.
Diese Bedingungen habe ich nun hoffentlich klargestellt. Sind sie erfüllt, kann man das so machen.