Forum: PC-Programmierung Netzwerkverbindung ohne IP-Adresse?

Bauform B. schrieb:
> Mahlzeit,
>
> kann man einen Debian-PC ohne (bzw. mit unbekannter) IP-Adresse
> irgendwie erreichen? Mit so einem Mittelding zwischen Wake-on-Lan (der
> PC läuft schon) und netcat (dafür fehlt die Adresse)? Die MAC weiß ich
> eigentlich auch nicht, aber das ließe sich ändern. Es würde reichen,
> wenn der ein einziges eindeutiges Paket empfängt. Daraufhin würde er das
> Netzwerk normal konfigurieren und den sshd starten.

Die MAC Adresse reicht aus. Über ARP wird die MAC Adresse aus der IP 
Adresse ermittelt. Hat man die MAC spart man sich diesen Schritt sogar.

> Es ist kein Notfall, ich installiere so einen PC gerade neu. Der soll
> auch in einem fremden, völlig unbekannten Netzwerk laufen, wo die
> Netzwerkkonfiguration evt. von Hand gemacht wird oder auch nicht.
> Deshalb möchte ich DHCP vermeiden, auch wenn damit alles ganz einfach
> funktionieren würde.

Der Kontext ist unklar. Was hat das eine mit dem anderen zu tun? Was 
hält dich davon ab die IP Konfiguration vorzunehmen damit du JETZT auf 
den PC zugreifen kannst? Was hat eine spätere anderen Konfiguration 
damit zu tun? Kostet dich jede IP Konfig extra oder wie sieht das aus?

Deine Frage zeigt auch eindeutige kritische Lücken in deinem Wissen über 
Netzwerktechnik. Evt. willst du diese schließen bevor du großmächtig 
irgendwelche PCs für irgendwelche Umgebungen installierst?

Cyblord -. schrieb:
> Was hält dich davon ab die IP Konfiguration vorzunehmen damit du JETZT auf
> den PC zugreifen kannst?

Nichts, jetzt ist er noch griffbereit.

> Was hat eine spätere anderen Konfiguration damit zu tun?
> Kostet dich jede IP Konfig extra oder wie sieht das aus?

Später steht er in einer Halle und ich müsste 12km fahren. In dem 
Zustand ist das Netzwerk zunächst nicht konfiguriert, anschließend 
spielt der Benutzer seine Konfiguration ein (oder nicht).

Unter Windows z.B.:
arp -s 157.55.85.212  00-aa-00-62-c6-09 ... Fügt statischen Eintrag 
hinzu.
unter Linux sicher ähnlich.
Im Lokalen Netz (ohne Router) läuft die Kommunikation nur über die MAC 
Adresse. Die Verbindung zwischen IP und MAC passiert über das ARP Adress 
Resolution Protokoll.
ifconfig zeigt auch die MAC Adresse an ohne das eine IP existiert.

Bauform B. schrieb:
> Später steht er in einer Halle und ich müsste 12km fahren.

Das klingt nach einer Verbindung über das Internet. Damit nützt Dir die 
MAC genau garnichts, die wird nur im lokalen Netz benutzt und vom Router 
ersetzt.

Bauform B. schrieb:
> Später steht er in einer Halle und ich müsste 12km fahren. In dem
> Zustand ist das Netzwerk zunächst nicht konfiguriert, anschließend
> spielt der Benutzer seine Konfiguration ein (oder nicht).

Ja nur dann hängt doch sowieso alles vom Nutzer und dessen Konfig ab. 
Was willst du dann da vorbereitend machen?
Das ganze hört sich wirklich wirr an. Wenn ein späterer Nutzer das alles 
konfiguriert dann klärt man mit diesem einen möglichen Fernzugriff.

Bauform B. schrieb:
> Mit so einem Mittelding zwischen Wake-on-Lan (der PC läuft schon) und
> netcat (dafür fehlt die Adresse)?

Hostname / DNS

Bauform B. schrieb:
> Es würde reichen,
> wenn der ein einziges eindeutiges Paket empfängt. Daraufhin würde er das
> Netzwerk normal konfigurieren und den sshd starten.

Im Prinzip geht das auf Basis der MAC-Adresse ohne jedwedes IP. Du 
müsstest einen Service schreiben, der mittels Raw Socket auf einen LAN 
Frame mit einem eigenen Ethertype horcht (wie 0x0800 IP und 0x0806 ARP) 
und daraufhin das Netz konfiguriert.

Dein Problem dürfte jedoch darin bestehen, dass dieses Verfahren nicht 
routet. Der Sender muss sich im gleichen Layer 2 Netz befinden. Über 
handelsübliche Router-Ketten vom Internet geht das nicht.

Bauform B. schrieb:

> Später steht er in einer Halle und ich müsste 12km fahren. In dem
> Zustand ist das Netzwerk zunächst nicht konfiguriert, anschließend
> spielt der Benutzer seine Konfiguration ein (oder nicht).

Der Benutzer konfiguriert und betreibt SEIN lokales Netz, und du 
möchtest versuchen, hinter seinem Rücken und ohne Beachtung seiner 
Routing-, Firewall- und sonstigen Regeln auf einen der Rechner im Netz 
zugreifen?

Cyblord -. schrieb:
> Ja nur dann hängt doch sowieso alles vom Nutzer und dessen Konfig ab.
> Was willst du dann da vorbereitend machen?

Wünschen würde ich mit einen Daemon, der an eth0 lauscht, egal, wie das 
konfiguriert ist. Wenn der ein "magisches Paket" empfängt, konfiguriert 
er eth0:1. Auf dem Kabel gibt es (auch) ein Subnetz für mich, damit ist 
auch das kein Problem:

Oliver R. schrieb:
> Das klingt nach einer Verbindung über das Internet. Damit nützt Dir die
> MAC genau garnichts

Rolf schrieb:
> hinter seinem Rücken und ohne Beachtung seiner
> Routing-, Firewall- und sonstigen Regeln auf einen der Rechner im Netz
> zugreifen?

Ist nicht so ungewöhnlich, wenn der Betreiber des Zielnetzes mit einer 
Fernwartung explizit einverstanden ist und ggf per Firewall 
kontrolliert. Je nach Grad der Sicherheitsphilosophie will er aber 
vielleicht keinen Zugriff auf das ganze Netz zulassen. In diesem Fall 
findet man bei Geräten unter Fremdwartung mitunter zwei Interfaces. 
Eines im Produktionsnetz und eines im Wartungsnetz oder direkt an einem 
Service-Router.

Rolf schrieb:
> Der Benutzer konfiguriert und betreibt SEIN lokales Netz, und du
> möchtest versuchen, hinter seinem Rücken und ohne Beachtung seiner
> Routing-, Firewall- und sonstigen Regeln auf einen der Rechner im Netz
> zugreifen?

Richtig -- nur nicht "hinter seinem Rücken", geheim oder zwielichtig ist 
da garnichts.

Bauform B. schrieb:
> Cyblord -. schrieb:
>> Ja nur dann hängt doch sowieso alles vom Nutzer und dessen Konfig ab.
>> Was willst du dann da vorbereitend machen?
>
> Wünschen würde ich mit einen Daemon, der an eth0 lauscht, egal, wie das
> konfiguriert ist. Wenn der ein "magisches Paket" empfängt, konfiguriert
> er eth0:1.

Und wie bekommst du überhaupt Zugriff auf den Rechner? Hat der eine 
öffentliche statische IP, gibt es NAT oder VPN?

> Auf dem Kabel gibt es (auch) ein Subnetz für mich

Was bedeutet das? Der Satz ergibt keinen Sinn. Subnetze gibt es bei IP 
und haben mit Kabeln nichts zu tun. Und mit Layer 2 auch nicht.

(prx) A. K. schrieb:
> Ist nicht so ungewöhnlich, wenn der Betreiber des Zielnetzes mit einer
> Fernwartung explizit einverstanden ist

Hier soll aber keine normale Fernwartung betrieben werden, sondern auf 
ein magisches Paket hin soll sich ein Netzwerkinterface um 
konfigurieren. Warum auch immer.
Mich würde interessieren warum eine normale Fernwartungslösung nicht in 
Frage kommt.

Bauform B. schrieb:

> kann man einen Debian-PC ohne (bzw. mit unbekannter) IP-Adresse
> irgendwie erreichen? Mit so einem Mittelding zwischen Wake-on-Lan (der
> PC läuft schon) und netcat (dafür fehlt die Adresse)? Die MAC weiß ich
> eigentlich auch nicht, aber das ließe sich ändern.

Du brauchst nur dafür zu sorgen, dass auf dem fraglichen PC irgendein 
Dienst läuft, der Broadcasts empfängt und Unicast antwortet.

Kinderkram.

Alle Verfahren ohne bereits vorher eingerichtetem IP leiden unter dem 
gleichen Problem: Routing geht eigentlich nicht. Es muss dort im Layer 2 
Netz eine bekannte Komponente geben, die mitspielt. Ist eine Art 
Henne-und-Ei Frage.

Das Routing freilich kann man überlisten, da keine bidirektionale 
Kommunikation erforderlich ist. Man sendet einen UDP-Frame mit 
gewünschter Ziel-IP und der bekannten MAC-Adresse. Wenn die Firewall das 
per NAT oder über eine VPN explizit zulässt, landet der beim Zielsystem.

Ob S. schrieb:
> Du brauchst nur dafür zu sorgen, dass auf dem fraglichen PC irgendein
> Dienst läuft, der Broadcasts empfängt und Unicast antwortet.

Broadcasts werden üblicherweise nicht geroutet.

(prx) A. K. schrieb:
> Das Routing freilich kann man überlisten

... muss dann aber im Zielsystem schon irgendein rudimentäres IP passend 
zum IP-Netz drauf haben, damit der überhaupt darauf horcht. Das 
Henne-und-Ei Problem. Routen muss das freilich nicht können.

(prx) A. K. schrieb:
> Ob S. schrieb:
>> Du brauchst nur dafür zu sorgen, dass auf dem fraglichen PC irgendein
>> Dienst läuft, der Broadcasts empfängt und Unicast antwortet.
>
> Broadcasts werden üblicherweise nicht geroutet.

Das ist wohl wahr. Aber der TO hatte ja bereits WOL in's Spiel gebracht. 
Scheint also die Möglichkeit zu haben, im Ziel-LAN WOL-Pakete zu 
erzeugen. Die Frage ist eigentlich dann nur noch: kann er den 
WOL-Paketen auch noch eigenen Extra-Payload verpassen?

Ob S. schrieb:
> Das ist wohl wahr. Aber der TO hatte ja bereits WOL in's Spiel gebracht.
> Scheint also die Möglichkeit zu haben, im Ziel-LAN WOL-Pakete zu
> erzeugen. Die Frage ist eigentlich dann nur noch: kann er den
> WOL-Paketen auch noch eigenen Extra-Payload verpassen?

Wozu? Wenn er Pakete ins lokale LAN senden kann, kann er schlicht 
beliebige Pakete senden.
Ein Dienst läuft auf dem PC und schaut welche Interfaces laufen und 
hängt sich ran und lauscht auf ein spezielles Paket.
Das geht schon. Ist aber Unsinn. Wenn es mit dem Wissen des Betreibers 
passiert, könnte man einfach ein Script schreiben welches der Betreiber 
nach seiner Konfig startet und welches ein Interface für die Fernwartung 
konfiguriert.
Was aber auch fragwürdig wäre, denn warum wird der PC nicht einmal 
korrekt, mit allen erforderlichen Interfaces konfiguriert? Wozu das 
Ganze?

Hier soll es aber wohl unter dem Radar ablaufen.

Cyblord -. schrieb:
> Hier soll aber keine normale Fernwartung betrieben werden

... sondern eine un-normale und Kosten sparende Fernwartung. So liest 
sich das jedenfalls.

Ich bin schon Backboxes begegnet, die über ARP über einem Service-PC im 
LAN konfiguriert wurden, weil keine Konsole und nix. Auf dem Service-PC 
Zieladresse und bekannte MAC in die ARP Liste eintragen, und dann PING. 
Die Kiste nahm einfach jede IP-Adresse, die bei ihr mit der richtigen 
MAC eintrudelte, als ihre an. Aus dem Netz heraus kam man dann vom 
Service-PC heraus ran. Nur ändert das nichts daran, dass man für solche 
Verfahren in ebendiesem Layer 2 Netz sein muss.

(prx) A. K. schrieb:

> ... sondern eine un-normale und Kosten sparende Fernwartung. So liest
> sich das jedenfalls.

Welche zusätzlichen Kosten fallen denn an, wenn man ein zusätzliches 
Interface für die Fernwartung direkt konfiguriert anstatt es später über 
magische Pakete zu tun?

> Nur ändert das nichts daran, dass man für solche
> Verfahren in ebendiesem Layer 2 Netz sein muss.

Was "Fernwartung" dann wieder ad absurdum führt. Dann ist es einfach ein 
(weiterer) Zugriff über was auch immer (ssh z.B.) und nichts anderes.

Cyblord -. schrieb:
> könnte man einfach ein Script schreiben welches der Betreiber
> nach seiner Konfig startet und welches ein Interface für die Fernwartung
> konfiguriert.

Was aber eine irgendwie geartete Konsole voraussetzt. Bei IoT-Devices 
hat man die oft nicht, was zu einiger Phantasie bei der 
Erstkonfiguration führt.

(prx) A. K. schrieb:
> Bei IoT-Devices

Bauform B. schrieb:
> kann man einen Debian-PC

Jaja

Und auch für IOT Devices gibt es bekannte Lösungen für die Einrichtung. 
DHCP wäre eine gute Lösung z.B. Oder eine default IP (vgl. Shellys).
Darum gehts hier aber nicht.

Cyblord -. schrieb:

> Wozu? Wenn er Pakete ins lokale LAN senden kann, kann er schlicht
> beliebige Pakete senden.

Nein. Es kann ja durchaus sein, dass er dazu wiederum einen Dienst 
benutzt, der nicht unter seiner Kontrolle steht.

Einfaches Beispiel: Fritzbox. Man kann darüber (mit den entsprechenden 
Rechten) WOL-Pakete in's LAN senden. Was man aber nicht kann: denen 
eigenen Payload zu verpassen. Und auch der Absender der WOL-Pakete ist 
zwingend die FB-LAN-Adresse.

Damit geht's also z.B. nicht.

Und das dürfte bei zumindest vielen "Internet-Routern" (sofern sie 
überhaupt das WOL-Feature haben) ganz genauso sein. Schon aus 
Sicherheitsgründen.

Ob S. schrieb:
> Nein. Es kann ja durchaus sein, dass er dazu wiederum einen Dienst
> benutzt, der nicht unter seiner Kontrolle steht.

Dann kann er auch kein eth Interface konfigurieren. Ganz einfach.
Abgesehen davon hat er zum Thema NAT usw. noch nichts geschrieben. Daher 
muss man davon ausgehen er hat vollen Zugriff aufs LAN. Wie auch immer.

Wenn du da dein eigenes Subnetz hast, liegt das vermutlich in
einem VLAN. Haenge also einfach einen DHCP-Server in dieses VLAN
und informiere den Netzbetreiber darueber. Der muss dann naemlich
das VLAN-Relaying fuer dieses Subnetz ausschalten.
Wenn dein Geraet dann initial "ausgerollt" ist, kannst du bei
deinem DHCP-Server nachsehen welche IP-Adresse dein Geraet hat.
Ueber die kannst du es dann ganz normal erreichen und eine statische
IP eintragen.

In einem aehnlich gelagerten Fall, wurde einfach mit einem NMAP
Pingscan nach neuen Adressen gesucht. Das waren dann die "Neuen".
Die wurden dann statisch konfiguriert und fettich war...

Den Pingscan koennte der Netzbetreiber dir aber uebelnehmen. :)

Stellersichnichtsoan!

Cyblord -. schrieb:
> Und wie bekommst du überhaupt Zugriff auf den Rechner? Hat der eine
> öffentliche statische IP

Der Rechner natürlich nicht, aber der Router, an dem er hängt. Dachte 
ich bis gerade eben :(

Cyblord -. schrieb:
> Daher muss man davon ausgehen er hat vollen Zugriff aufs LAN.

Nein, hat er doch nur vielleicht. Damit und überhaupt wird mir das Ganze 
zu unübersichtlich. Die Lösung

(prx) A. K. schrieb:
> Cyblord -. schrieb:
>> könnte man einfach ein Script schreiben welches der Betreiber
>> nach seiner Konfig startet und welches ein Interface für die Fernwartung
>> konfiguriert.
>
> Was aber eine irgendwie geartete Konsole voraussetzt. Bei IoT-Devices
> hat man die oft nicht, was zu einiger Phantasie bei der
> Erstkonfiguration führt.

ist viel realistischer, auch, wenn's keine Tastatur gibt. Früher hat man 
DIL-Schalter oder Jumper benutzt ;) Auf jedem Fall vielen Dank für die 
Aufklärung!

Bauform B. schrieb:
> Der Rechner natürlich nicht, aber der Router, an dem er hängt. Dachte
> ich bis gerade eben :(

Wenn Business-Anschluss, stehen die Chancen gut. Sonst kanns auf eine 
dynamische oder halbstatische IP rauslaufen, und das vielleicht nur über 
IPv6.

Cyblord -. schrieb:

> Dann kann er auch kein eth Interface konfigurieren.

Braucht er auch nicht. Wieder einfaches Beispiel, speziell für dich, da 
du anscheinend den Wink mit dem Zaunpfahl nicht kapierst: Also wieder: 
Fritzbox.

Da hast du (selbst als "Admin") nicht das Recht, zu machen was du 
willst. Der "Admin" ist halt nicht root. Und das dürfte bei der 
überwältigenden Mehrheit der kommerziellen Internet-GWs nicht anders 
sein. Und nicht nur bezüglich der der so abschätzig beurteilen 
"Plastic-Consumer-Router".

Da wird kein NIC-Interface konfiguriert. Sondern nur ein Dienst des GW 
benutzt, über den es möglich ist, WOL-Broadcasts in's LAN zu versenden.

Ich kenne aus eigener Erfahrung z.B.: Unify (UDMPro)->same behaviour

> Abgesehen davon hat er zum Thema NAT usw. noch nichts geschrieben. Daher
> muss man davon ausgehen er hat vollen Zugriff aufs LAN.

Eher nicht. Wenn er den hätte, wäre die ganze Frage ziemlich unsinnig. 
Allerdings: der TO ist BauformB. Würde also wiederum doch irgendwie 
passen...

Motopick schrieb:
> ...NMAP Pingscan...
> Den Pingscan koennte der Netzbetreiber dir aber uebelnehmen. :)

Wie uebel wäre wohl ein Test auf 2 bis 3 bestimmte Adressen? So mit 
"arping -i eth0 -c1 -0 192.168.178.1". Das gibt doch nur je 1 bis 2 ganz 
harmlose alltägliche Pakete, oder? Damit wüsste ich immerhin, ob ich in 
einem bekannten Netz bin und könnte eine passende Config benutzen oder 
mich still verhalten.

Bei IPv6 hast du immer auch Link-Local Adressen (fe80::...), die aus der 
MAC-Adresse erzeugt werden. Hast Du die MAC, hast Du die zugehörige IP. 
Die ist zwar nur in der aktuellen Broadcast Domain erreichbar, aber das 
reicht ja oft auch. Damit musst Du nichts umkonfigurieren, das ist eh 
immer da.

fchk

Frank K. schrieb:
> Bei IPv6 hast du immer auch Link-Local Adressen (fe80::...)

Man kann das auch ausschalten. Ist aber ein bisschen ein Krampf. Das ist 
von einem meiner Server:

1

root@duck:~# ifconfig eth0

2

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

3

        inet 10.60.1.2  netmask 255.255.255.0  broadcast 10.60.1.255

4

        inet6 fc00:4::a3c:102  prefixlen 120  scopeid 0x0<global>

5

        ether 00:ff:01:01:02:01  txqueuelen 1000  (Ethernet)

6

        RX packets 807036  bytes 108349431 (103.3 MiB)

7

        RX errors 0  dropped 0  overruns 0  frame 0

8

        TX packets 1015386  bytes 161836278 (154.3 MiB)

9

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

10

11

root@duck:~#

Man kann das zwar nicht immer machen. Ein Router geht z.B. nicht ohne 
das link-local zeug. Sollte man nur machen, wenn man weiss, was man tut, 
und sich sicher ist, das man es wirklich nicht braucht.

> Das gibt doch nur je 1 bis 2 ganz
> harmlose alltägliche Pakete

Ja die stoeren wohl keinen.

> Damit wüsste ich immerhin, ob ich in
> einem bekannten Netz bin und könnte eine passende Config benutzen oder
> mich still verhalten.

Nach einem zuverlaessigen guten Plan klingt das aber auch nicht.
Wenn man Technik ausrollt, sollte das ganze schon etwas besser sein.
Wenn man sich keinen Wolf laufen will...

Einen zuverlaessigen Plan habe ich uebrigens oben skizziert.

Lass sich das Netzwerk-Interface über DHCP konfigurieren und greife über 
einen Reverse-Proxy-Dienst wie Ngrok z.B. auf ssh zu. Wenn das Netzwerk 
vor Ort nicht kooperiert, hast Du meist eh verloren. Dann hilft nur noch 
Zugriff über Mobilfunk oder evtl. offene Hotspots.
https://www.endtoend.ai/tutorial/ngrok-ssh-forwarding/

Bauform B. schrieb:
> kann man einen Debian-PC ohne (bzw. mit unbekannter) IP-Adresse
> irgendwie erreichen? Mit so einem Mittelding zwischen Wake-on-Lan (der
> PC läuft schon) und netcat (dafür fehlt die Adresse)? Die MAC weiß ich
> eigentlich auch nicht, aber das ließe sich ändern. Es würde reichen,
> wenn der ein einziges eindeutiges Paket empfängt. Daraufhin würde er das
> Netzwerk normal konfigurieren und den sshd starten.
>
> Es ist kein Notfall, ich installiere so einen PC gerade neu. Der soll
> auch in einem fremden, völlig unbekannten Netzwerk laufen, wo die
> Netzwerkkonfiguration evt. von Hand gemacht wird oder auch nicht.
> Deshalb möchte ich DHCP vermeiden, auch wenn damit alles ganz einfach
> funktionieren würde.

Auch nachdem ich den ganzen Thread gelesen habe, fällt es mir immer noch 
einigermaßen schwer zu verstehen, was das Ganze soll. Dein "eindeutiges 
Paket" muß ja irgendwo her kommen, Du würdest dazu erstens ein Programm 
brauchen, das das Paket versendet, und ein zweites Programm, welches es 
empfängt. Wenn Du nicht in dem betreffenden Netzwerk bist, dann ist das 
jedenfalls nicht ganz einfach.

Was ich allerdings verstanden zu haben glaube, ist, daß es dabei um eine 
Art (womöglich temporären) Fernwartungszugang gehen soll. Ist das 
korrekt? Wenn ja, dann wäre mein Ansatz ein anderer -- entweder ein VPN 
oder sogar ein einfacher SSH-Tunnel, den Dein Fernzuwartender optional 
bei Bedarf starten und stoppen kann. Damit wäre netzwerkseitig nur ein 
kleiner Server im Internet nötig, den die Maschine erreichen kann, im 
Prinzip und mit ein paar Tricks würde da sogar ein Docker- oder 
LXC-Container ausreichen.

Der Rest wäre relativ überschaubar: autossh(1) installieren, dazu ein 
systemd-Unitfile in (zB.) /etc/systemd/system/autossh_username.service 
(bitte unten meine Anmerkungen zu Ersetzungen beachten) ablegen, und 
zwar mit dem folgenden Inhalt:

1

[Unit]

2

Description=Keeps a tunnel to 'example.com' open

3

After=network-online.target ssh.service

4

5

[Service]

6

User=username

7

Group=username

8

Environment=AUTOSSH_GATETIME=0

9

ExecStart=autossh \

10

  -NT \

11

  -o "ExitOnForwardFailure=yes" \

12

  -o "ServerAliveInterval=10" \

13

  -o "ServerAliveCountMax=3" \

14

  -M 9999 \

15

  -R '*:2424:localhost:22' \

16

  username@example.com

17

ExecStop=/usr/bin/killall -9 autossh

18

RestartSec=5

19

Restart=always

20

21

[Install]

22

WantedBy=multi-user.target

Überall muß dazu natürlich <username> durch den gültigen Benutzernamen 
und <example.com> durch den DNS-auflösbaren Hostname Deines Servers oder 
durch dessen IP-Adresse ersetzt werden.

Außerdem muß für den User <username> ein SSH-Schlüsselpaar mit 
ssh-keygen(1) erzeugt werden und sein öffentlicher Schlüssel auf dem 
Server in die Datei "$HOME/.ssh/authorized_keys" kopiert werden, damit 
der Login ohne Paßwort funktioniert. Für das Kopieren gibt es das 
Programm ssh-copy-id(1), dazu muß allerdings noch die 
Paßwort-Authentifizierung eingeschaltet sein. Wenn ssh-copy-id(1) den 
öffentlichen Schlüssel kopiert hat und der User und Du Euch ohne 
Paßworteingabe einloggen könnt, dann zur Verbesserung Eurer Sicherheit 
die Konfigurationsdirektive "PasswordAuthentication no" in die Datei 
/etc/ssh/sshd_config eingetragen und der SSH-Server restarten.

Wenn diese Unit läuft, würde sie die Verbindung dauerhaft offenhalten, 
und dann bist Du von außen mit "ssh -p 2424 example.com" sofort da.

Okay, die Verbindung soll nicht dauerhaft offen sein? Dann kannst Du den 
Kunden befähigen, sie bei Bedarf zu starten und zu stoppen, natürlich 
ohne ihm gleich Root-Zugang zu geben. Alles was es dazu braucht, ist 
eine kleine Datei in /etc/sudoers.d/username (remember, <username> 
ersetzen!) mit dem Inhalt:

1

username hostname=(root:root) NOPASSWD: \

2

  /usr/bin/systemctl start autossh_username.service, \

3

  /usr/bin/systemctl stop autossh_username.service, \

4

  /usr/bin/systemctl is-active autossh_username.service, \

5

  /usr/bin/systemctl status autossh_username.service

(Auch hier natürlich die Sache mit den Ersetzungen, zusätzlich 
<hostname> durch den hostnamen (nicht den FQDN) ersetzen. Die 
Subcommands "is-active" und "status" gibt es hier nur der Bequemlichkeit 
halber, dazu braucht der Benutzer keine Privilegien; der erste Befehl 
prüft ob der Service läuft; wenn ja, gibt er "active" aus und 0 zurück, 
wenn nein, gibt er "inactive" aus und etwas != 0 zurück, und "status" 
wirst Du ja sicherlich ohnehin schon längst kennen.)

Dazu im Zweifel noch ein cleveres Shell- oder Pythonskript mit Desktop-, 
Startmenü- oder Programmstarter-Verknüpfungen, wenn Du Deinem User keine 
Shellbefehle zumuten möchtest, dann kann er das schick über Mausklicks 
starten, stoppen, und sich anzeigen lassen, ob der Tunnel läuft. Analog 
funktioniert das natürlich auch mit OpenVPN oder Wireguard.

Mit diesen einfachen Tricks kannst Du die Maschine netzwerkseitig 
einfach mit DHCP ausliefern und kannst Dir den ganzen Krams mit der 
Konfiguration spezieller Dienste zum Starten eigener Netzwerk-Interfaces 
sparen... Wie auch immer: viel Spaß und Erfolg!

Angenommen, klassisches IPv4 Firmennetz. Das Ganze ist ein bekanntes 
mehrstufiges Problem:

1. IP Adresse im lokalen Netzwerk (das "L" in LAN) bekommen

Dafür gibt es einen Zoo von Protokollen die unter der Überschrift 
"ZeroConf" (Zero-configuration networking) laufen.

Aber, so richtig zu Ende gedacht wurden die nie. Wenn der Rechner nicht 
gerade in einer Firma von IT-mäßig degenerierten Eisenbiegern 
installiert wird, dann sind ZeroConf-Protokolle jetzt auch nicht gerade 
die Lieblinge der lokalen IT. Da will man nämlich Kontrolle drüber haben 
was so im eigenen Netzzwerk passiert.

Für einige ZeroConf-Protokolle und verwandte Dienste muss auch eine 
gewisse Infrastruktur im LAN vorhanden sein. Daher würde ich nicht auf 
ZeroConf setzen.

Die lokale IT hat zu entscheiden wie sie dem Ding eine lokale IP-Adresse 
verpasst. Zum Beispiel statisch konfiguriert oder mittels DHCP. Das muss 
der lokale ITler am Gerät auswählen können.

ZeroConf-Protokolle kann man zwar auf dem Rechner aktiviert haben, aber 
eine lokale IT die was taugt wird nicht drauf setzen. Außer vielleicht 
um anfänglich mal Zugriff auf den Rechner zu bekommen.

2. Ausgehende Verbindungen (Rechner als Client)

Darf der Rechner Verbindungen zu Servern im Internet aufbauen? Auch das 
entscheidet und konfiguriert letztendlich die lokale IT, und zwar 
komplett außerhalb des Rechners. Nämlich dadurch dass auf der Firewall 
ins Internet ausgehender Traffic (und welcher) erlaubt oder verboten 
wird. Da wird man wahrscheinlich eine Voreinstellung haben, aber egal 
was, das macht nicht der Rechner.

Von anderen Lösungen, wie VPNs reden wir mal nicht. Auch das muss mit 
Hilfe der lokalen IT aufgebaut werden.

3. Eingehende Verbindungen (Rechner als Server)

Hier gibt es was, nämlich den UPnP-Dreck und ähnliche Sicherheits- 
Alpträume, mit dem ein Rechner eine Firewall/NAT eigenständig 
konfigurier. Ein ITler der dass in einem Firmennetz zulässt ist die 
größte Pfeife vor dem Herren.

Da würde ich nie im Leben drauf bauen.

Fazit: Diese Idee, ich stell da einen Rechner hin, der sich magisch, auf 
Zuruf aus 12km Entfernung komplett konfiguriert ist illusorisch. Der 
Rechner hat von der lokalen IT ins Netz gebracht zu werden. Zuerst ins 
LAN, und sei es mit DHCP, dann ins WAN.

Danach kann man darüber reden ob er sich automatisch weitere 
Konfigurationsinformationen von einem Server im Internet zieht.

Frank K. schrieb:
> Bei IPv6 hast du immer auch Link-Local Adressen (fe80::...), die
> aus der MAC-Adresse erzeugt werden. Hast Du die MAC, hast Du die
> zugehörige IP. Die ist zwar nur in der aktuellen Broadcast Domain
> erreichbar, aber das reicht ja oft auch. Damit musst Du nichts
> umkonfigurieren, das ist eh immer da.

Das Interface muss nur UP sein, dann funktioniert es sofort und immer. 
Das wäre doch die perfekte Lösung, jedenfalls für mich. Ja, bei diesem 
Rechner ist der MAC-Aufkleber natürlich innen und im eingebauten Zustand 
sind ca. 12 Schrauben im Weg. Aber sonst, wo ist der Fehler?


Ein T. schrieb:
> Was ich allerdings verstanden zu haben glaube, ist, daß es dabei um eine
> Art (womöglich temporären) Fernwartungszugang gehen soll. Ist das
> korrekt? Wenn ja, dann wäre mein Ansatz ein anderer -- entweder ein VPN
> oder sogar ein einfacher SSH-Tunnel, den Dein Fernzuwartender optional
> bei Bedarf starten und stoppen kann.

Ja, tatsächlich wurde es früher so ähnlich gemacht, das funktioniert 
theoretisch einfach und übersichtlich, praktisch war es manchmal ein 
wenig umständlich.

Hannes J. schrieb:
> Dafür gibt es einen Zoo von Protokollen die unter der Überschrift
> "ZeroConf" (Zero-configuration networking) laufen.
> Aber, so richtig zu Ende gedacht wurden die nie.

So ganz pauschal will ich ja ZeroConf, aber garantiert nicht mit avahi 
;)

> Darf der Rechner Verbindungen zu Servern im Internet aufbauen?

Sehr unwahrscheinlich, weil unnötig.

> Von anderen Lösungen, wie VPNs reden wir mal nicht.
> Fazit: Der Rechner hat von der lokalen IT ins Netz gebracht zu werden.
> Zuerst ins LAN, und sei es mit DHCP, dann ins WAN.

Nicht unbedingt der Rechner, ein extra Service-Rechner geht auch, 
wahrscheinlich einfacher und mit mehr Möglichkeiten. Von dem aus 
funktioniert dann die Link Local Verbindung.

Bauform B. schrieb:
> Ja, tatsächlich wurde es früher so ähnlich gemacht, das funktioniert
> theoretisch einfach und übersichtlich, praktisch war es manchmal ein
> wenig umständlich.

Darf ich fragen, inwiefern das umständlich war? Vielleicht würde es sich 
wesentlich einfacher gestalten, die Umständlichkeit hinaus zu werfen, 
als eine esoterische Spezialkonstruktion zu basteln... :-)

>> Darf der Rechner Verbindungen zu Servern im Internet aufbauen?
>
> Sehr unwahrscheinlich, weil unnötig.

Der bekommt keine Updates? 8-O


Edit: Update-Frage hinzugefügt.

Ein T. schrieb:
>>> Darf der Rechner Verbindungen zu Servern im Internet aufbauen?
>> Sehr unwahrscheinlich, weil unnötig.
> Der bekommt keine Updates? 8-O

Man wünscht sich, dass der Rechner auch ohne jede Netzwerkverbindung 
funktioniert. Also müssen Updates per USB-Stick möglich sein. Also sind 
Updates jederzeit möglich, aber mangels Internet auch nicht so dringend.

> Bauform B. schrieb:
>> Ja, tatsächlich wurde es früher so ähnlich gemacht, das funktioniert
>> theoretisch einfach und übersichtlich, praktisch war es manchmal ein
>> wenig umständlich.
>
> Darf ich fragen, inwiefern das umständlich war? Vielleicht würde es sich
> wesentlich einfacher gestalten, die Umständlichkeit hinaus zu werfen,
> als eine esoterische Spezialkonstruktion zu basteln... :-)

Umständlich war es, wenn ich erst jemand finden musste, der es bedient.
Meine ursprüngliche Idee war sicher extrem, aber die Verbindung per Link 
Local ist doch die Lösung und sicher nicht esoterisch, ganz im 
Gegenteil.

Was er ja eigentlich will ist dass sich die Rechner ohne Netzwerk-Config 
erstmal finden, und dann selber passend Konfigurieren. Also eigentlich 
DHCP, aber kein "echtes" DHCP, weil das nicht verwendet werden soll bzw. 
sich mit dem bereits vorhandenen DHCP im Netzwerk beißt.

Wär' also z.B. eine einfache Lösung mit wenig Aufwand, auf den Rechnern 
DHCP auf einem Nicht-Standard-Port laufen zu lassen. (Option "-p xxxx" 
für dhcpd und dhclient)

Bauform B. schrieb:
> Auf dem Kabel gibt es (auch) ein Subnetz für mich, damit ist
> auch das kein Problem:

Insofern würde sich die Subnetze vom Firmen-DHCP und dem Zusatz-DHCP 
auch nicht stören. Dein DHCPd verwaltet einfach dein Subnetz, 
fertig.

Bauform B. schrieb:
> Man wünscht sich, dass der Rechner auch ohne jede Netzwerkverbindung
> funktioniert. Also müssen Updates per USB-Stick möglich sein. Also sind
> Updates jederzeit möglich, aber mangels Internet auch nicht so dringend.

Hm, vielleicht verstehe ich es ja nicht, aber... "jederzeit möglich" 
beißt sich doch ein wenig mit "USB-Stick", oder? Irgendwie müßte der 
Stick doch vorhanden und idealerweise halbwegs aktuell sein. Wäre da 
nicht eventuell sowas wie "unattended-upgrades" sinnvoll, gerade unter 
Debian? Das wäre doch sehr komfortabel: wenn das Netzwerk / Internet da 
ist, dann macht er seine Aktualisierungen, und wenn nicht, schreibt er 
eine Fehlermeldung in seine Logdateien und gut ist.

> Umständlich war es, wenn ich erst jemand finden musste, der es bedient.

Oh... dort gibt es niemanden, der bei Bedarf auf einen Knopf in einer 
GUI oder einem Webinterface drücken kann?

Ein T. schrieb:
> Bauform B. schrieb:
>> Man wünscht sich, dass der Rechner auch ohne jede Netzwerkverbindung
>> funktioniert. Also müssen Updates per USB-Stick möglich sein. Also sind
>> Updates jederzeit möglich, aber mangels Internet auch nicht so dringend.
>
> Hm, vielleicht verstehe ich es ja nicht, aber... "jederzeit möglich"
> beißt sich doch ein wenig mit "USB-Stick", oder?

"ohne jede Netzwerkverbindung" kann bedeuten, dass es auf dem Grundstück 
überhaupt nichts Netzwerk-ähnliches gibt, keine Telefonleitung, kein 
GSM. Also ist "jederzeit", wenn der Benutzer Zeit und Lust hat, da hin 
zu fahren und ein Update zu machen. Ganz allgemein macht man bei solchen 
Rechnern nur ungern Updates - Never touch a running system.

Es gibt auch Installationen mit "normalem" Netzwerk, aber die sind von 
außen dermaßen nicht erreichbar. Da dauert ein Antrag auf einen 
offiziellen Service-Zugang   Wochen, der Client braucht ein Dongle und 
vor lauter Sicherheit funktioniert das im Ernstfall nicht. Aus so einem 
Netzwerk heraus darf der Rechner natürlich auch nicht einfach so ins 
Internet. Und daran ist sowas schon mal gescheitert:

> Wäre da nicht eventuell sowas wie "unattended-upgrades" sinnvoll,
> gerade unter Debian?

Debian arbeitet sicher sehr gewissenhaft, aber das riskiere ich dann 
doch nicht.

>> Umständlich war es, wenn ich erst jemand finden musste, der es bedient.

> Oh... dort gibt es niemanden, der bei Bedarf auf einen Knopf in einer
> GUI oder einem Webinterface drücken kann?

Selbst wenn der zufällig in der Nähe ist, muss ich erst telefonieren. 
Ich dachte halt, das muss doch auch komfortabler gehen.

(prx) A. K. schrieb:
> Ist nicht so ungewöhnlich, wenn der Betreiber des Zielnetzes mit einer
> Fernwartung explizit einverstanden ist und ggf per Firewall
> kontrolliert.

Stell ihn doch ins Tor / Darknet. Eigenes Relay + Keys für so etwas wie 
ein Subnet (Gammel-VPN) DURCH das Internet hindurch. "Family-Keys und 
Member" Da kannst du EINGEHENDE Verbindungen auf deinen Host per Port 80 
u. 433 (für Fernwartungs-Software und Statusabfragen, "dein Knopf"), und 
auch Port 22 (für SSH auf die Konsole) direkt nutzen.

DAS ALLES ABER OHNE Portforwarding oder Änderungen in zwischen liegenden 
Netzen, Firewalls oder Router(n). Ja Henne-Ei: Du brauchst trotzdem 
zuerst eine IP.

--> War nur ein Scherz: Mach lieber ne "richtige" VPN, wenn du nachher 
nochmal drauf musst.

Tim S. schrieb:
> Stell ihn doch ins Tor / Darknet. (...)
> Ja Henne-Ei: Du brauchst trotzdem zuerst eine IP.

:) ja, irgendwas ist immer...

Manchmal hilft es, wenn man rausfinden kann, ob man mit einem bekannten 
Netz verbunden ist. Dafür kann dann die vordefinierte Konfiguration 
geladen werden und in einem unbekannten Netz bleibt alles 
unkonfiguriert. Man muss nur ein paar Sekunden lauschen und nach Freund 
und Feind sortieren

1

tcpdump -n -t -l -U -s 128 -i eth0 arp

Aber das solideste sind immer noch DIL-Schalter oder Kodierstecker ;)

Bauform B. schrieb:
> "ohne jede Netzwerkverbindung" kann bedeuten, dass es auf dem Grundstück
> überhaupt nichts Netzwerk-ähnliches gibt, keine Telefonleitung, kein
> GSM.

das hat Stuxnet aber auch nicht gehindert eine SPS umzukonfigurieren

Alexander schrieb:
> das hat Stuxnet aber auch nicht gehindert eine SPS umzukonfigurieren

Das kam dann über Gehirnstrahlen aus dem Weltall. Dafür sind nämlich die 
GPS-Satelliten eigentlich da. Steht so im Internet, schwarz auf weiß.

Alexander schrieb:
> das hat Stuxnet aber auch nicht gehindert eine SPS umzukonfigurieren

Man sollte schon den Unterschied zwischen "kein (ungefilterter) 
Internetzugang" und "überhaupt kein Netzwerk" kennen.

Stuxnet wurde zwar auf USB-Sticks reingeholt, der Rest lief aber über 
das Netzwerk.

Meine "Systemwiederherstellung" unter EndeavourOS ("Arch Linux") heißt: 
Timeshift mit installiertem BTRFS Dateisystem.

X. H. schrieb:
> Meine "Systemwiederherstellung" unter EndeavourOS ("Arch Linux") heißt:
> Timeshift mit installiertem BTRFS Dateisystem.

Und bei Arch-Linux braucht man das? Das spricht nicht gerade dafür. 
Falls dir das nicht klar sein sollte...