TCP Port x-IP Server Client Modell

[LadyGaga (Gast)]

Hallo zusammen,
ich möchte eine Client Server Modell System Testen,
ich soll ein Server starten sowie Mehrere Client.
dafür brauche ich einen Port und Mehrere IP Adressen.
wie kann ich in Meinem Rechner Mehrere IP benutzen ohne eine neue 
Virtuell Maschine zu installieren
Grüße

[Stefan F. (Gast)]

LadyGaga schrieb:
> wie kann ich in Meinem Rechner Mehrere IP benutzen

Du hast vergessen wenigstens dein Betriebssystem zu nennen. In den 
meisten Linux Desktops geht das in der "Systemsteuerung" wo man auch die 
ganzen Netzwerk-parameter einstellt.

Linux Server werden meist in der Date /etc/network/interfaces 
konfiguriert. Zum Beispiel:

# Die primäre IP-Adresse des Servers
auto eth0
iface eth0 inet static
address 192.168.2.41
netmask 255.255.255.0
gateway 192.168.2.1

# IP-Adresse für Test Node 1
auto eth0:0
iface eth0:0 inet static
address 192.168.2.201
netmask 255.255.255.0

# IP-Adresse für Test Node 2
auto eth0:1
iface eth0:1 inet static
address 192.168.2.202
netmask 255.255.255.0

Windows können dir andere Leute besser erklären.

[LadyGaga (Gast)]

Hallo,
vielen Dank.
das stimmt das habe ich vergessen zu sagen.
der Test sollte unter Windows 10 durchgeführt werden.
Grüße

[(prx) A. K. (prx)]

Baust du die Clients selbst?

[Dirk B. (dirkb2)]

LadyGaga schrieb:
> dafür brauche ich einen Port und Mehrere IP Adressen.

Warum kann man den Client nicht mehrmals auf derselben Maschine starten?

[LadyGaga (Gast)]

ja, dazu darf ich keine physikalische Konfiguration durchführen.
ich denke, ich brauche so zu sagen eine Virtuell Netzwerk.

[LadyGaga (Gast)]

Hallo
>Warum kann man den Client nicht mehrmals auf derselben Maschine starten?

Nach Server start (in c# programiert) der Listner wartet auf eine 
Verbindung mit dem Client. die Clients melden über IP Adresse und Port 
beim Server.
der Server bearbeitet die Daten und sollte jede Client daten senden. er 
selber erkennt der Clients anhand ihe IP Adresse

[Stefan F. (Gast)]

Dirk B. schrieb:
> Warum kann man den Client nicht mehrmals auf derselben Maschine starten?

Kann man, wenn du bei jedem Client einstellen kannst, an welche IP 
Adresse er gebunden werden soll. Wenn der Client das nicht kann, würde 
ich ihn in einen Docker Container packen.

[Dirk B. (dirkb2)]

Stefan ⛄ F. schrieb:
> Dirk B. schrieb:
>> Warum kann man den Client nicht mehrmals auf derselben Maschine starten?
>
> Kann man, wenn du bei jedem Client einstellen kannst, an welche IP
> Adresse er gebunden werden soll.
>
> Und wenn der Cient das nicht kann, würde ich ihn in einen Docker
> Container packen. Aber das ist auch schon Linux Spezifisch. Windows ist
> halt nicht für Entwickler gemacht.

Mach ich bei Putty, Firefox und selbstgeschriebenen Clients auch nicht.
Trotzdem sendet der Server die Daten nur an den anfragenden Client.

[Stefan F. (Gast)]

Dirk B. schrieb:
> Mach ich bei Putty, Firefox und selbstgeschriebenen Clients auch nicht.
> Trotzdem sendet der Server die Daten nur an den anfragenden Client.

Mag sein, aber er will halt jedem Client eine eigene IP Adresse geben.

Eigene Ports wären zweifellos einfacher gewesen, die hätten sich von 
selbst ergeben.

[Axel S. (a-za-z0-9)]

LadyGaga schrieb:

> ich möchte eine Client Server Modell System Testen,
> ich soll ein Server starten sowie Mehrere Client.
> dafür brauche ich einen Port und Mehrere IP Adressen.

Nein, die brauchst du dafür nicht.


LadyGaga schrieb:
> ja, dazu darf ich keine physikalische Konfiguration durchführen.

Machst du nicht. Brauchst du auch nicht.

> ich denke, ich brauche so zu sagen eine Virtuell Netzwerk.

Das wäre der Fall, wenn du mehrere virtuelle Maschinen hättest. Kannst 
du natürlich machen, aber (du ahnst es bestimmt) brauchst du nicht.


LadyGaga schrieb:
>
> Nach Server start (in c# programiert) der Listner wartet auf eine
> Verbindung mit dem Client.

So funktioniert ein TCP-Server, ja.

> die Clients melden über IP Adresse und Port beim Server.

Nein. Der Server erkennt einen (neuen) Client daran, daß ein Socket 
(neu) geöffnet wird, über den jemand mit ihm redet.

> der Server bearbeitet die Daten und sollte jede Client daten senden.

Ja. Dazu verwendet der Server aber den Socket. Das ist praktisch das 
gleiche, wie ein Filehandle. Nur das man darauf schreiben und davon 
lesen kann.

> er selber erkennt der Clients anhand ihe IP Adresse

Nein. Die IP-Adresse des Clients interessiert den Server zumindest für 
die Kommunikation überhaupt nicht. Er kann sie natürlich abfragen, z.B. 
für ein Logfile.


PS: das ist übrigens das falsche Forum.

[Stefan F. (Gast)]

Axel S. schrieb:
>> er selber erkennt der Clients anhand ihe IP Adresse
> Nein. Die IP-Adresse des Clients interessiert den Server zumindest für
> die Kommunikation überhaupt nicht.

Du sprichst vom Betriebssystem. Aber du weißt nicht, was seine Server 
Anwendung mit der IP Adresse macht. Es kommt vor, dass Menschen andere 
Menschen oder Maschinen anhand ihrer vermeintlich eindeutigen IP Adresse 
erkennen wollen.

Ob das beim TO so Sinn macht, wissen wir nicht. Dafür hat er zu wenige 
Infos herausgerückt.

Ich erkenne meinen Drucker jedenfalls anhand seiner wirklich festen IP 
Adresse. Darum kann mir egal sein, dass er seinen Namen manchmal spontan 
ändert (weiß der Geier warum er das tut, die Firmware hat einige 
Macken).

[Christian H. (netzwanze)]

Wir haben einige MDE-Clients in der Firma, die tatsächlich über deren IP 
identifiziert werden. Sie verbinden sich mit dem Server alle per HTTPS 
und übermitteln darüber Daten. Das ist ungefähr das, was der TO 
nachbilden will.
Ich hätte das zwar anders gemacht (und zwar dass sich die Clients über 
einen Namen beim Server anmelden), ist aber leider so gekauft worden.

[Axel S. (a-za-z0-9)]

Stefan ⛄ F. schrieb:
> Axel S. schrieb:
>>> er selber erkennt der Clients anhand ihe IP Adresse
>> Nein. Die IP-Adresse des Clients interessiert den Server zumindest für
>> die Kommunikation überhaupt nicht.
>
> Du sprichst vom Betriebssystem.

Ich spreche vom Programm "Server". Ein TCP-Server signalisert seine 
Bereitschaft zur Kommunikation üblicherweise mit listen(2) und nimmt 
eine neue Verbindung mit accept(2) an. Das alles hantiert mit einer 
Datenstruktur namens Socket. Die kann eine IP-Adresse zugeordnet 
haben, muß aber nicht.

> Aber du weißt nicht, was seine Server
> Anwendung mit der IP Adresse macht. Es kommt vor, dass Menschen andere
> Menschen oder Maschinen anhand ihrer vermeintlich eindeutigen IP Adresse
> erkennen wollen.

Kann schon sein. Aber auch dann redet er mit dem Teilnehmer über den 
Socket. Sogar wenn er die Verbindung nur kommentarlos schließt, 
verwendet er den Socket mit close(2).

> Ob das beim TO so Sinn macht, wissen wir nicht. Dafür hat er zu wenige
> Infos herausgerückt.

Natürlich nicht. Seine Frage bezog sich ja auch auf das Netzwerk, das er 
glaubt zum Testen seines Servers zu brauchen. Er braucht aber eigentlich 
nur ein netzwerkfähiges Betriebssystem. Das muß noch nicht mal eine 
Netzwerkkarte (physisch oder virtuell) haben. Das loopback Network 
(127.0.0.1) reicht schon.


Ich empfehle den Buchklassiker von Richard Stevens, "Programmieren von 
Unix-Netzen". Er nutzt zwar WinDOS und C#. Aber die Grundlagen sind die 
gleichen.

[Harry L. (mysth)]

Stefan ⛄ F. schrieb:
> Mag sein, aber er will halt jedem Client eine eigene IP Adresse geben.

Mein, will er nicht!
Er Bindet sich an die kombination aus IP und Port
Und Nein! - damit ist nicht die Port-Nummer gemeint, auf der der Server 
lauscht, sondern die, de für die Gegenrichtung ausgehandelt wird.

[Axel S. (a-za-z0-9)]

Harry L. schrieb:
> Stefan ⛄ F. schrieb:
>> Mag sein, aber er will halt jedem Client eine eigene IP Adresse geben.
>
> Mein, will er nicht!

Ich hatte ihn so verstanden. Aber nicht, ob er das aus freien Stücken 
will, oder ob er glaubt, das zu brauchen.

> Er Bindet sich an die kombination aus IP und Port
> Und Nein! - damit ist nicht die Port-Nummer gemeint, auf der der Server
> lauscht, sondern die, de für die Gegenrichtung ausgehandelt wird.

Ja. Aber auf die hat er ja keinen Einfluß. Und er hat die Kombination 
ja schon, wenn sich ein Client verbindet. Der Server muß sich nicht mehr 
separat mit dem Client verbinden. In dem Moment, wenn accept(2) 
zurückkehrt, steht die Verbindung schon.

[Harry L. (mysth)]

Axel S. schrieb:
> Ja. Aber auf die hat er ja keinen Einfluß. Und er hat die Kombination
> ja schon, wenn sich ein Client verbindet. Der Server muß sich nicht mehr
> separat mit dem Client verbinden. In dem Moment, wenn accept(2)
> zurückkehrt, steht die Verbindung schon.

Ich habe nichts Gegenteiliges geschrieben...

[Daniel A. (daniel-a)]

Das ganze könnte man mit network namespeces, veth pairs, und einer 
bridge realisieren. Zumindest unter linux. Beispiel: (Muss als root 
ausgeführt werden)

#!/bin/bash

# Bridge "br-fake-switch" erstellen. Ist wie ein switch
ip link add br-fake-switch type bridge
ip link set br-fake-switch up

# Ein veth pair (ist wie ein kabel), interfaces vm-server und vs-server werden erstellt, was am einen ende rein geht, kommt am andern raus
# Dann wird vm-server zur Bridge br-fake-switch hinzugefügt, dann der netzwerk namespace vnet-server erstellt, vs-server da rein verschoben,
# und dann noch die IP usw. von den Interfacen im Namespace konfiguriert
ip link add vm-server type veth peer vs-server
ip link set vm-server master br-fake-switch
ip netns add vnet-server
ip link set vs-server netns vnet-server
ip netns exec vnet-server ip addr add 10.83.5.2/24 dev vs-server
ip netns exec vnet-server ip link set lo up
ip netns exec vnet-server ip link set vs-server up

# Nochmal das selbe, für einen weiteren neuen NS
ip link add vm-client1 type veth peer vs-client1
ip link set vm-client1 master br-fake-switch
ip netns add vnet-client1
ip link set vs-client1 netns vnet-client1
ip netns exec vnet-client1 ip addr add 10.83.5.3/24 dev vs-client1
ip netns exec vnet-client1 ip link set lo up
ip netns exec vnet-client1 ip link set vs-client1 up

# Nochmal das selbe, für einen weiteren neuen NS
ip link add vm-client2 type veth peer vs-client2
ip link set vm-client2 master br-fake-switch
ip netns add vnet-client2
ip link set vs-client2 netns vnet-client2
ip netns exec vnet-client2 ip addr add 10.83.5.4/24 dev vs-client2
ip netns exec vnet-client2 ip link set lo up
ip netns exec vnet-client2 ip link set vs-client2 up

Mit "ip netns exec [ns] [commando]" kann man Kommandos in einem netns 
ausführen. z.B. "ip netns exec vnet-server bash", dann hat man ne bash 
session in der netns, und alle Kommandos die man da eingibt sind in dem 
netns. "ip netns exec" braucht zwar auch root (zumindest in diesem 
speziellen fall, es gibt ausnahmen), aber man kann danach mit "su - 
username" wieder zu einem user wechseln.

Zum illustrieren, wie das Netzwerk aus Sicht der diversen NS aussieht:

root@phenix:~# brctl show
bridge name  bridge id    STP enabled  interfaces
br-fake-switch    8000.0edc7e8e6272  no    vm-client1
              vm-client2
              vm-server
root@phenix:~# ip addr show up
...
6: br-fake-switch: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 0e:dc:7e:8e:62:72 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2c0d:63ff:fe3f:ccb7/64 scope link 
       valid_lft forever preferred_lft forever
8: vm-server@if7: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-fake-switch state LOWERLAYERDOWN group default qlen 1000
    link/ether e2:19:42:66:84:95 brd ff:ff:ff:ff:ff:ff link-netns vnet-server
10: vm-client1@if9: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-fake-switch state LOWERLAYERDOWN group default qlen 1000
    link/ether 0e:dc:7e:8e:62:72 brd ff:ff:ff:ff:ff:ff link-netns vnet-client1
12: vm-client2@if11: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-fake-switch state LOWERLAYERDOWN group default qlen 1000
    link/ether 12:50:9c:d9:f8:1e brd ff:ff:ff:ff:ff:ff link-netns vnet-client2

root@phenix:~# ip netns exec vnet-server ip addr show up
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
7: vs-server@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 12:71:82:95:c7:62 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.83.5.2/24 scope global vs-server
       valid_lft forever preferred_lft forever
    inet6 fe80::1071:82ff:fe95:c762/64 scope link 
       valid_lft forever preferred_lft forever

root@phenix:~# ip netns exec vnet-client1 ip addr show up
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
9: vs-client1@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether be:11:6f:f9:95:54 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.83.5.3/24 scope global vs-client1
       valid_lft forever preferred_lft forever
    inet6 fe80::bc11:6fff:fef9:9554/64 scope link 
       valid_lft forever preferred_lft forever

root@phenix:~# ip netns exec vnet-client2 ip addr show up
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
11: vs-client2@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 0a:60:ae:22:b7:df brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.83.5.4/24 scope global vs-client2
       valid_lft forever preferred_lft forever
    inet6 fe80::860:aeff:fe22:b7df/64 scope link 
       valid_lft forever preferred_lft forever

So hast man quasi schonmal 3 netns, mit eigener IP, interface, und 
verbunden mit nem switch (der bridge).

All die namen der Interfaces und Namespaces kann man natürlich frei 
wählen. Sie dürfen aber nicht zu lange sein, das limit für 
interfacenamen ist recht klein...

Wenn du vom Host aus auf die Netns zugreifen willst, musst du der Bridge 
auch noch eine IP mit cidr geben.

Wenn die Sachem im Netns ins Internet können sollen, musst du die auch 
irgendwie daran anschliessen. z.B. das ethernet interface in die Bridge, 
oder auf dem Host ip forwarding zeugs und/oder NAT einrichten. In den 
Netzwerk Namespacen musst du natürlich dann noch die default route usw. 
setzen.

Am ende sollte man natürlich wieder aufräumen:

#!/bin/bash
ip link del br-fake-switch
ip link del vm-client1
ip link del vm-client2
ip link del vm-server
ip netns del vnet-server
ip netns del vnet-client1
ip netns del vnet-client2

Den Teil mit dem erstellen vom netns, und ein Programm darin ausführen, 
könnte man natürlich in ein script oder so zur wiederverwendung packen: 
(ungetestet)

#!/bin/bash
set -e

if [ $# -lt 3 ]
then
  echo "Usage: $0 name addr cmd..."
  exit 1
fi

name="$1"; shift
addr="$1"; shift

ip netns add "vnet-$name"

cleanup(){
  ip link del "vm-$name"
  ip netns del "vnet-$name"
}
trap cleanup EXIT INT TERM

ip link add "vm-$name" type veth peer "vs-name"
ip link set "vm-$name" master br-fake-switch
ip link set "vs-$name" netns "vnet-$name"
ip netns exec "vnet-$name" ip addr add "$addr" dev "vs-$name"
ip netns exec "vnet-$name" ip link set lo up
ip netns exec "vnet-$name" ip link set "vs-$name" up

ip netns exec "vnet-$name" "$@"

[Axel S. (a-za-z0-9)]

Daniel A. schrieb:
> Das ganze könnte man mit network namespeces, veth pairs, und einer
> bridge realisieren. Zumindest unter linux

Dein Enthusiasmus in allen Ehren. Aber ein simpler Network-Alias wie von 
Stefan im 
Beitrag "Re: TCP Port x-IP Server Client Modell" 
gezeigt, reicht dafür vollkommen aus. Mutmaßlich braucht man nichts 
dergleichen. Einen einfachen TCP-Server setzt man als Fingerübung mal 
eben auf. Dito den dazu passenden Client. Z.B. einen Server, der echo 
oder rot13 implementiert. Und dann läßt man sie auf dem selben Node (vm, 
whatever) aufeinander los.

Und ich gehe jede Wette ein, daß in C# ein entsprechendes Beispiel schon 
fertig ist. Der TE ist doch bloß ein Student, der faul ist, sich das 
anzulesen. Und die Vorlesung hat er geschwänzt.

[Stefan F. (Gast)]

Axel S. schrieb:
> Dein Enthusiasmus in allen Ehren. Aber ein simpler Network-Alias
> reicht dafür vollkommen aus.

Ich finde trotzdem super, dass Daniel auch diese Variante beschrieben 
hat. Vor allem so ausführlich.

Axel S. schrieb:
> Der TE ist doch bloß ein Student, der faul ist

Vielleicht muss er auch unter Windows entwickeln, da ist das nicht so 
einfach. Mein herzliches Beileid dazu.

[c-hater (Gast)]

Stefan ⛄ F. schrieb:

> Axel S. schrieb:
>> Dein Enthusiasmus in allen Ehren. Aber ein simpler Network-Alias
>> reicht dafür vollkommen aus.
>
> Ich finde trotzdem super, dass Daniel auch diese Variante beschrieben
> hat. Vor allem so ausführlich.
>
> Axel S. schrieb:
>> Der TE ist doch bloß ein Student, der faul ist
>
> Vielleicht muss er auch unter Windows entwickeln, da ist das nicht so
> einfach.

Wie bitte?

Um unter Windows mehrere IPs an eine NIC zu hängen, brauche ich nicht in 
die Untiefen der Editierung irgendwelcher Textdateien abzusteigen, 
gefolgt von einem (oder u.U. mehreren) kryptischen Kommandos. Wobei 
sowohl der Ort als auch der Inhalt der Dateien als auch der Name und die 
Parameter der Kommandos obendrein auch noch je nach konkreter 
Linux-Spielart deutlich differieren können.

Unter Windows sind das ein paar Klicks im GUI und fertig isses. Und das 
ziemlich einheitlich seit Jahrzehnten auf immer dieselbe Art. Nur der 
Weg zum richtigen Dialog variiert, seitdem die Kachel-Manie bei 
Microsoft ausgebrochen ist, also seit Windows8. Letztlich kommt man aber 
auch bei Windows11 immer noch zum guten altbekannten Explorer-Objekt für 
die NICs. Welches im Übrigen viel mehr Funktionalität bereitstellt als 
z.B. /etc/network/interfaces bei den debilen (ähem... debianischen oder 
wie sagt man das richtig?) Linuxen.
Um all das unter Linux machen zu können, was damit möglich ist, muss man 
schon sehr tief in Linux einsteigen, mit unzähligen, quer über das 
System verstreuten Konfigurationsdateien und vielen, absolut kryptischen 
Kommandos hantieren.

OK, alles machbar. Aber Sackstand pur im Vergleich zu der federleichten 
Art, das Zeug in Windows zu konfigurieren.

Nur dann, wenn man was konfigurieren will, was Microsoft im GUI nicht 
vorgesehen hat (was allerdings eher selten vorkommt), dann wird es auch 
unter Windows richtig nervig.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Daniel A. schrieb:
> Das ganze könnte man mit network namespeces, veth pairs, und einer
> bridge realisieren. Zumindest unter linux. Beispiel: (Muss als root
> ausgeführt werden)
>
> [code]
> #!/bin/bash

Das ist ja nun mehrfach ins Knie geschossen. Um nicht zu sagen, einmal 
mit der Maschinenpistole auf Knie gehalten.

Erstens brauch man alles nicht, weil der:die Fragesteller:in sich mit 
großer Wahrscheinlichkeit verrannt hat und nicht verstanden hat dass bei 
TCP/IP die Beteiligten eindeutig über ein 5-Tupel assoziiert sind 
[Protokoll (z.B. TCP oder UDP), lokale IP-Adresse, lokaler Port, 
entfernte IP-Adresse, entfernter Port]

Wenn nur ein einziges dieser 5 Daten unterschiedlich ist haben wir eine 
andere Assoziation. Bei TCP würde man sagen eine andere Verbindung.

Wenn man dann noch wie üblich Clients so programmiert, dass sie 
ephemeral Ports verwenden, dann braucht man nicht mehr. Dann haben wir 
Clients die auf dem selben Rechner, mit der selben IP-Adresse (und sei 
es localhost 127.0.0.1), mit jeweils unterschiedliche Ports laufen, und 
damit unterschiedliche und eindeutige Client-Server Assoziationen.

Zweitens, wenn man schon kompliziertere Netzwerk-Konfigurationen macht, 
dann doch nicht händisch mit ip, ifupdown, nmcli oder was zur 
Hölle es da noch auf der Kommandozeile gibt. Schön deklarativ mit 
Netplan und der Tag ist dein Freund.

https://netplan.io/
https://netplan.io/examples/

Ach ja, und an den den Windows-Clown der sich beschwert dass es kein GUI 
gibt. Doch, gibt es natürlich. Natürlich auch mehrere. Aber dazu ein GUI 
nehmen ist wie sich zusätzlich noch in das andere Knie schießen. Man 
könnte auch sage nur für Leute, die beim Dummklicken in GUIs einen 
freudigen Erregungszustand erreichen.

[Stefan F. (Gast)]

c-hater, beschreibe doch mal die Vorgehensweise für Ahnungslose wie den 
TO, damit er das auch unter Windows nachvollziehen kann.

Vielleicht wird dann nebenbei auch klar, warum Linux Benutzer lieber ein 
paar Befehle oder Config Files zitieren, anstatt den Weg per GUI zu 
zeigen (den es durchaus gibt).

[c-hater (Gast)]

Hannes J. schrieb:

> Ach ja, und an den den Windows-Clown der sich beschwert dass es kein GUI
> gibt. Doch, gibt es natürlich. Natürlich auch mehrere.

Ja, genau das ist das Problem (zumindest eins der Probleme). Jeder Idiot 
will's unbedingt anders machen als alle anderen. Aber keiner macht's 
auch nur annähernd so gut wie Microsoft.

Du Löffelschnitzer solltest kapieren, das ich mich in beiden Welten sehr 
gut auskenne und sehr wohl in der Lage bin, die jeweiligen Vor- und 
Nachteile abzuschätzen. Und in diesem Punkt liegt Microsoft ganz klar 
weit vorne.

> Aber dazu ein GUI
> nehmen ist wie sich zusätzlich noch in das andere Knie schießen.

Warum? Warum sollte man für die simple Aufgabe, weitere IPs an ein 
Interface zu hängen, was anderes als ein genauso simples GUI verwenden 
müssen? Das ist doch Unsinn.

Mal abgesehen davon, dass es für Hardcore-CLI-Fetischisten auch unter 
Windows natürlich den für sie passenden Weg gibt. Man kann es sich auf 
Wunsch auch beliebig kompliziert machen...

[sio (Gast)]

Da hat der  c-hater (Gast) absolut recht.
Auch ih kenne mich in beiden Welten aus und ich finde diese Unart,
das jede Linux Distribution ihr eigenes Süppchen kocht und dazu auch 
noch ab und an die Rezepte ändert einfach zum Kotzen.

Duraus ein Grund dafür warum Linux nicht so "gelenkig" daherkommt wie 
der eine odere andere ,äh Löffelschnitzer meint.

Traurig, das sich LINUX hier völlig unnötigerweise selbst im Weg steht.
Vereinheitlichung und Standards sind der Weg zum Erfolg und nicht so 
etwas!!!

[Daniel A. (daniel-a)]

Hannes J. schrieb:
> Erstens brauch man alles nicht, weil der:die Fragesteller:in sich mit
> großer Wahrscheinlichkeit verrannt hat und nicht verstanden hat dass bei
> TCP/IP die Beteiligten eindeutig über ein 5-Tupel assoziiert sind
> [Protokoll (z.B. TCP oder UDP), lokale IP-Adresse, lokaler Port,
> entfernte IP-Adresse, entfernter Port]

Davon würde ich nicht ausgehen. Es geht um unbekannt Client & Server 
Programm, wer weiss, was diese intern machen. Villeicht nutzen die 
Clients UDP Mulicast oder so, mit fixer Adresse. Oder vielleicht wird 
die IP von der Serveranwendung dummer weise statt einem Session Token 
oder so verwendet, statt richtiges Session Handling zu implementieren. 
Wer weiss, mit wass der TO sich da herum quälen muss.

c-hater schrieb:
> Um unter Windows mehrere IPs an eine NIC zu hängen, brauche ich nicht in
> die Untiefen der Editierung irgendwelcher Textdateien abzusteigen,
> gefolgt von einem (oder u.U. mehreren) kryptischen Kommandos

Heutzutage installieren die meisten Distros - zumindest wenn man eine 
Desktop Umgebung installiert - so weit ich weiss NetworkManager. Dort 
kann man auch mehrere IPs usw. für ein Interface bequem per GUI 
einstellen.

c-hater schrieb:
> Letztlich kommt man aber
> auch bei Windows11 immer noch zum guten altbekannten Explorer-Objekt für
> die NICs. Welches im Übrigen viel mehr Funktionalität bereitstellt als
> z.B. /etc/network/interfaces bei den debilen (ähem... debianischen oder
> wie sagt man das richtig?) Linuxen.

Einige sehen die Datei mittlerweile als veraltet an. Ich bin mir nicht 
sicher, ob es in debian überhaupt noch standardmässig verwendet wird.

Aber in der Datei da kann man beliebige Kommandos ausführen lassen, z.B. 
wenn das Interface hoch kommt usw. "up commando". Gibt unter anderem 
{pre-,,post-}{up,down}. Zusätzlich ist es erweiterbar, man kann da also 
beliebige Optionen usw. erfinden, wenn man will. Anders als bei einem 
GUI-Dialog, gibt es also nichts, was man da nicht einstellen könnte.

c-hater schrieb:
> Nur dann, wenn man was konfigurieren will, was Microsoft im GUI nicht
> vorgesehen hat (was allerdings eher selten vorkommt), dann wird es auch
> unter Windows richtig nervig.

Sowas, wie ich in meinem letzten Beitrag gepostet habe, kann man meines 
Wissens in Windows nicht machen (mal abgesehen von der WSL2, aber das 
ist ja eine Linux VM).
Das ist nämlich bei weitem nicht nur dem Host mehrere IPs geben. 
Stattdessen sehen Programme in unterschiedlichen Netzwerk Namespaces 
eine komplett eigene und unabhängige Netzwerkkonfiguration, mit 
separaten Interfaces, Routing, etc. Und bei dem Beispiel komplett ohne 
einen vollständigen Container oder eine VM aufsetzen zu müssen, da 
schalte ich nur gerade den Netzwerkteil für ein Programm um.

Der Grund, warum ich das gezeigt habe, statt einfach das Setzen mehrerer 
IPs beim Host ist, dass man beim Programm nicht einstellen können muss, 
welche es nimmt.

Bei Serveranwendungen ist es üblich, angeben zu können, auf welchem Port 
auf Verbindungen gewartet wird. Bei Clients wäre es vermutlich auch 
möglich, zu implementieren, dass eine bestimmte IP zum initiieren einer 
Verbindung verwendet wird.

Aber, in beiden fällen muss das Programm es auch zulassen, dass man das 
konfigurieren kann. Das sieht nämlich alle IPs. Und bei Client 
Programmen ist das eher unüblich, denen ist das in der regel egal, von 
wo aus das zum Ziel kommt. Dann hätte man zwar mehrere IPs, aber kann 
den Client nicht dazu bringen, eine Bestimmte zu nutzen, bzw. eine 
andere, als andere Instanzen.

Indem man das Programm aber einfach in einem Netzwerk Namespace startet, 
kann man das Problem umgehen. Das Programm sieht dann einfach die 
Netzwerk config von dem Netzwerk Namespace, nutzt die IPs, die da 
eingestellt sind, usw.

[Stefan F. (Gast)]

Ich finde es eine Unart von Windows, den Desktop mit jeder Version 
halbherzig umzugestalten und mich dazu zwingen, diesen einen neuen 
Desktop zu verwenden.

Bei Linux genieße ich hingegen die freie Wahl. Wem dazu viel ist, der 
kann ja einfach bei dem bleiben, was er kennt. Niemand ist zum Wechsel 
gezwungen. Also wo ist das Problem?

Übrigens fehlt immer noch die Anleitung für Windows 10.

[c-hater (Gast)]

Daniel A. schrieb:

> Heutzutage installieren die meisten Distros - zumindest wenn man eine
> Desktop Umgebung installiert - so weit ich weiss NetworkManager. Dort
> kann man auch mehrere IPs usw. für ein Interface bequem per GUI
> einstellen.

Das stimmt. Diese Einstellung ist vorgesehen. Nur: Es funktioniert halt 
oft schlicht nicht.

>> z.B. /etc/network/interfaces bei den debilen (ähem... debianischen oder
>> wie sagt man das richtig?) Linuxen.
>
> Einige sehen die Datei mittlerweile als veraltet an. Ich bin mir nicht
> sicher, ob es in debian überhaupt noch standardmässig verwendet wird.

Wird sie. Zum Glück. Das ist das einzige, auf was man bein Debian und 
seinen Abkömmlingen zählen kann, weil der NM alle Interfaces in Ruhe 
läßt, die schon darüber konfiguriert sind...

> Sowas, wie ich in meinem letzten Beitrag gepostet habe, kann man meines
> Wissens in Windows nicht machen

Dann braucht es wohl auch (näherungsweise) niemand. Das genau ist der 
Punkt...

Was genau macht diese Scheiße eigentlich deiner Meinung nach?

[sio (Gast)]

Stefan ⛄ F. schrieb:
> Übrigens fehlt immer noch die Anleitung für Windows 10.

Dazu braucht es keine Anleitung, das schafft jeder Karusellbremser.

[Stefan F. (Gast)]

sio schrieb:
>> Übrigens fehlt immer noch die Anleitung für Windows 10.
> Dazu braucht es keine Anleitung, das schafft jeder Karusellbremser.

Worum geht es dann in diesem Thread?

[Phato (Gast)]

Stefan ⛄ F. schrieb:
> sio schrieb:
>>> Übrigens fehlt immer noch die Anleitung für Windows 10.
>> Dazu braucht es keine Anleitung, das schafft jeder Karusellbremser.
>
> Worum geht es dann in diesem Thread?

Um Dich, immer nur um Dich…

[Stefan F. (Gast)]

Nachdem sich Leute über das vorgeblich komplizierte Linux aufgeregt 
haben, zeige ich hier den grafischen Weg, den ich ganz oben in der 
ersten Antwort meinte.

Wie konfiguriert man denn jetzt in Windows?

[Frank K. (fchk)]

Stefan ⛄ F. schrieb:

> Wie konfiguriert man denn jetzt in Windows?

Ähnlich.

fchk

[Stefan F. (Gast)]

Frank K. schrieb:
>> Wie konfiguriert man das denn jetzt in Windows?
> Ähnlich.

Na, sieht doch fast gleich aus.