Loopback address Was: merkwürdiges ssh Verbindungsproblem

[Florian Lohoff]

Hola,

On Wed, Jan 15, 2025 at 01:10:46PM +0100, Kai 'wusel' Siering wrote:
> Moin,
> 
> am 09.01.25 um 10:22 schrieb Florian Lohoff:
> > > > Also reserved war 127/8 schon seit 1981 :)
> > > 
> > > Schon. Und es wird mir immer ein Rätsel bleiben, warum man dafür das
> > > letzte Class-A- statt des letzten Class-C-Netzes ver(sch)wendet hat.
> > 
> > Es ist ein byte compare um zu wissen ob es localhost ist ;) Und wenn man
> > packet forwarding macht das in hardware zu machen ist halt viel
> > einfacher abzubilden. Erstes byte 0x7f -> Sollte nicht "on wire" sein.
> 
> Nachvollziehbar, aber gerade für local*host* sind 16 Millionen IP(v4)-
> Adressen vollkommener Overkill. Und den Byte-Compare hätte man auch mit
> 255/8 erschlagen können, aber egal, IPv6 löst das IP-Adressen-Knapp-
> heitsproblem ja ;-)

Damals (TM) in 60er Jahren waren 20 Hosts am Internet. Software war
langsam, hardware groß und Teuer. Netzwerkinterfaces waren in 74er
Logik, diskret aufgebaute Kisten groß wie ein Kühlschrank. 

Über 24 Mio Hosts MEHR am Netz hat damals niemand nachgedacht. 

"640Kbyte is enough" (Bill Gates 1981)
"There is no reason for any individual to have a computer in his home."
(DEC 1977)

> Kernel 1.2.13 wäre demnach RH 1.1/2.0 und 1995?
> 
> > Kernel 1.2.13 - mal schnell geguckt - Ging auch da im ARP schon nicht:
> > 
> > net/inet/arp.c
> >     626 /*
> >     627  *      Check for bad requests for 127.0.0.1.  If this is one such, delete it.
> >     628  */
> >     629         if(tip == INADDR_LOOPBACK)
> >     630         {
> >     631                 kfree_skb(skb, FREE_READ);
> >     632                 return 0;
> >     633         }
> 
> Hmm, was, wenn man die MAC statisch auf eine IP mappte? Ich bin mir jedenfalls
> *sehr* sicher, daß ich das seinerzeit mit Adressen aus 127/8 aufgebaut hatte
> und nach einem (Kernel-) Update das nicht mehr funktionierte (die aktualisierte
> Kiste wollte nix mehr von 127/8 auf dem Ethernet wissen, tcpdump zeigte nix
> mehr, IIRC auch nicht eingehend).

Siehe den 2. snippet. Wenn es AUS einem interface rausgesendet wird,
wird die source addresse durch die interface addresse ersetzt. Also auch
in 1.2.13 ging das nicht. ARP hat es gekillt, und auch ip output. 

Hab mal schnell in 0.99.13 geguckt - Das ist ja so mit das erste bei
linux was mal einen IP Stack hatte - auch da war ARP schon unterbunden,
ip input hat alles von 127.0.0.1 gefressen. 

Hast du das vielleicht mit Solaris gemacht als alter Sun Apologet?

> > Z.b. wenn du via Apache VHosts hast - Dann willst du vielleicht mit
> > anderen namen arbeiten.
> 
> Aber die klebe ich dann doch nicht in die hosts als 127.1.2.3?

Siehe systemd-resolved auf 127.0.0.53 - Das ist total schlau das so zu
machen weil du dann dem socket multibind problem aus dem weg gehst,
trotzdem das aber nur von localhost erreichbar ist.

> > Das network-started target ist aber explizit für den geneigten Admin
> > eine configurationsfrage. Du _kannst_ das Nutzen - musst das aber
> > nicht
> 
> Allein, systemd-Skripte von nginx und Co. warten darauf, und ohne systemd-
> networkd funktioniert das nicht so, wie erwartet. Dann startet systemd jene
> Units und nginx oder ntpd binden sich auf Adressen, die z. B. noch tentative
> sind, brechen so mit Schmackes ins Essen. Aber das ist ein ganz anderer Thread ;)

Wie gesagt - lies die Doku - Man kann in systemd-networkd definieren
welche interfaces da sein sollen/müssen das das netz als "up" markiert
wird. Wenn du /etc/network/interfaces oder netplan oder was auch immer
nutzt ist die frage die die das machen. Wenn du network/interfaces
nimmst wartet die systemd unit auf nix per default.

Flo
-- 
Florian Lohoff                                                     f at zz.de
  Any sufficiently advanced technology is indistinguishable from magic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20250116/60e21621/attachment.sig>