Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Verbindungsproblem
1 view
Skip to first unread message
Alexander Goetzenstein
May 8, 2023, 8:16:36 AM5/8/23
to
Hallo,
hier habe ich einen Server unter openSUSE Tumbleweed, der im
Normalbetrieb keine Routen ins böse Internet hat. Zudem sperrt die
Kindersicherung und Profil in der Fritz!Box den Zugang nach außen.
Wenn ich nun ein Update o.ä. vorhabe, setze ich die default route auf
die Fritz!Box und schalte Kindersicherung aus und das Profil um (alles
vorübergehend, versteht sich). Trotzdem erhält der Server keine
Verbindung nach draußen:
> # ping -c 4 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) Bytes an Daten.
> Von 192.168.221.5 icmp_seq=1 Zielhost nicht erreichbar
> Von 192.168.221.5 icmp_seq=2 Zielhost nicht erreichbar
> Von 192.168.221.5 icmp_seq=3 Zielhost nicht erreichbar
> Von 192.168.221.5 icmp_seq=4 Zielhost nicht erreichbar
>
> --- 8.8.8.8 ping-Statistik ---
> 4 Pakete übertragen, 0 empfangen, +4 Fehler, 100% packet loss, time 3078ms
> pipe 3
Das ändert sich leider erst nach einem Reboot. Da dieser vorliegend
recht aufwendig ist, würde ich mir den gerne sparen. Wie kann ich mich
der Ursache und damit der Lösung nähern?
--
Gruß
Alex
hier habe ich einen Server unter openSUSE Tumbleweed, der im
Normalbetrieb keine Routen ins böse Internet hat. Zudem sperrt die
Kindersicherung und Profil in der Fritz!Box den Zugang nach außen.
Wenn ich nun ein Update o.ä. vorhabe, setze ich die default route auf
die Fritz!Box und schalte Kindersicherung aus und das Profil um (alles
vorübergehend, versteht sich). Trotzdem erhält der Server keine
Verbindung nach draußen:
> # ping -c 4 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) Bytes an Daten.
> Von 192.168.221.5 icmp_seq=1 Zielhost nicht erreichbar
> Von 192.168.221.5 icmp_seq=2 Zielhost nicht erreichbar
> Von 192.168.221.5 icmp_seq=3 Zielhost nicht erreichbar
> Von 192.168.221.5 icmp_seq=4 Zielhost nicht erreichbar
>
> --- 8.8.8.8 ping-Statistik ---
> 4 Pakete übertragen, 0 empfangen, +4 Fehler, 100% packet loss, time 3078ms
> pipe 3
Das ändert sich leider erst nach einem Reboot. Da dieser vorliegend
recht aufwendig ist, würde ich mir den gerne sparen. Wie kann ich mich
der Ursache und damit der Lösung nähern?
--
Gruß
Alex
Marco Moock
May 8, 2023, 8:53:44 AM5/8/23
to
Am 08.05.2023 um 14:16:32 Uhr schrieb Alexander Goetzenstein:
> Das ändert sich leider erst nach einem Reboot. Da dieser vorliegend
> recht aufwendig ist, würde ich mir den gerne sparen. Wie kann ich mich
> der Ursache und damit der Lösung nähern?
Zeige mal die Route
> Das ändert sich leider erst nach einem Reboot. Da dieser vorliegend
> recht aufwendig ist, würde ich mir den gerne sparen. Wie kann ich mich
> der Ursache und damit der Lösung nähern?
ip route
ip -6 route
Wie hast du das Routing konfiguriert?
Eventuell kommen sich Verwaltungsprogramme mit eigenen Skripten etc. in
die Quere.
Alexander Goetzenstein
May 8, 2023, 10:03:36 AM5/8/23
to
Hallo,
Am 08.05.23 um 14:51 schrieb Marco Moock:
> Wie hast du das Routing konfiguriert?
Dafür habe ich ein Script. Wesentlicher Inhalt:
> ## Wenn Internet-Zugriff benötigt wird:
> echo 'Schnittstellen einstellen...'
> ip link set eno1 up
> sleep 1
> ip link set eno2 down
> sleep 1
> ip link set enp1s0f0 up
> sleep 1
> ip link set enp1s0f1 down
> sleep 1
>
> ## IP-Adresse zuweisen
> echo 'IP-Adressen zuweisen...'
> ip addr add 192.168.221.5/24 dev eno1
> sleep 1
> ip addr del 192.168.221.16/24 dev eno2
> sleep 1
> ip addr add 192.168.5.1/32 dev enp1s0f0
> sleep 1
> ip addr flush dev enp1s0f1
> sleep 1
>
> ## Routing einstellen
> echo 'Routing einstellen...'
> ip route del $(ip route show | grep eno1 | cut -d' ' -f 1) dev eno1 2>/dev/null
> sleep 1
> ip route add 192.168.5.0/24 dev enp1s0f0 ## route für iSCSI zu rs3617XS
> sleep 1
> ip route del $(ip route show | grep enp1s0f1 | cut -d' ' -f 1) dev enp1s0f1 2>/dev/null
> sleep 1
> ip route add default dev eno1
> sleep 1
> ip addr | grep -e UP -e DOWN
> ip route show
eno1 ist das produktive Beinchen, das ins Internet zeigen soll, enp1s0f0
verbindet zu den Festplatten. Der Rest wird nicht gebraucht und soll
abgeschaltet sein. Die sleeps habe ich eingebaut, da sich gezeigt hat,
dass es ohne im Script nicht immer zuverlässig schaltet, einzeln manuell
ausgeführt aber schon.
Soweit ich gesehen habe, sind die Routen OK, und das ping geht bis zur
Fritz!Box -aber eben nicht weiter. Umgekehrt meine ich mich auch daran
zu erinnern (ist schon etwas her), dass auch eine neu gesetzte Sperre in
der Fritz!Box erst wirkung zeigte, nachdem der Server neu gestartet
wurde. Vielleicht triggert das ja etwas in der Fritz!Box? Falls dem so
sein könnte: wie könnte man das triggern ohne Reboot?
> Eventuell kommen sich Verwaltungsprogramme mit eigenen Skripten etc. in
> die Quere.
Welche könnten dies sein?
Bislang gehe ich davon aus, das alles zu Fuß auf der Kommandozeile zu
machen. Jedenfalls ist mir nicht bewusst, irgendeine Automatik benutzt
zu haben, aber man weiß ja nie, was SUSE da alles gestrickt hat, was ich
nur noch nicht kenne.
--
Gruß
Alex
Am 08.05.23 um 14:51 schrieb Marco Moock:
> Am 08.05.2023 um 14:16:32 Uhr schrieb Alexander Goetzenstein:
>
>> Das ändert sich leider erst nach einem Reboot. Da dieser vorliegend
>> recht aufwendig ist, würde ich mir den gerne sparen. Wie kann ich mich
>> der Ursache und damit der Lösung nähern?
>
> Zeige mal die Route
> ip route
> ip -6 route
mach ich später, Datensicherung läuft gerade.
>
>> Das ändert sich leider erst nach einem Reboot. Da dieser vorliegend
>> recht aufwendig ist, würde ich mir den gerne sparen. Wie kann ich mich
>> der Ursache und damit der Lösung nähern?
>
> Zeige mal die Route
> ip route
> ip -6 route
> Wie hast du das Routing konfiguriert?
> ## Wenn Internet-Zugriff benötigt wird:
> echo 'Schnittstellen einstellen...'
> ip link set eno1 up
> sleep 1
> ip link set eno2 down
> sleep 1
> ip link set enp1s0f0 up
> sleep 1
> ip link set enp1s0f1 down
> sleep 1
>
> ## IP-Adresse zuweisen
> echo 'IP-Adressen zuweisen...'
> ip addr add 192.168.221.5/24 dev eno1
> sleep 1
> ip addr del 192.168.221.16/24 dev eno2
> sleep 1
> ip addr add 192.168.5.1/32 dev enp1s0f0
> sleep 1
> ip addr flush dev enp1s0f1
> sleep 1
>
> ## Routing einstellen
> echo 'Routing einstellen...'
> ip route del $(ip route show | grep eno1 | cut -d' ' -f 1) dev eno1 2>/dev/null
> sleep 1
> ip route add 192.168.5.0/24 dev enp1s0f0 ## route für iSCSI zu rs3617XS
> sleep 1
> ip route del $(ip route show | grep enp1s0f1 | cut -d' ' -f 1) dev enp1s0f1 2>/dev/null
> sleep 1
> ip route add default dev eno1
> sleep 1
> ip addr | grep -e UP -e DOWN
> ip route show
eno1 ist das produktive Beinchen, das ins Internet zeigen soll, enp1s0f0
verbindet zu den Festplatten. Der Rest wird nicht gebraucht und soll
abgeschaltet sein. Die sleeps habe ich eingebaut, da sich gezeigt hat,
dass es ohne im Script nicht immer zuverlässig schaltet, einzeln manuell
ausgeführt aber schon.
Soweit ich gesehen habe, sind die Routen OK, und das ping geht bis zur
Fritz!Box -aber eben nicht weiter. Umgekehrt meine ich mich auch daran
zu erinnern (ist schon etwas her), dass auch eine neu gesetzte Sperre in
der Fritz!Box erst wirkung zeigte, nachdem der Server neu gestartet
wurde. Vielleicht triggert das ja etwas in der Fritz!Box? Falls dem so
sein könnte: wie könnte man das triggern ohne Reboot?
> Eventuell kommen sich Verwaltungsprogramme mit eigenen Skripten etc. in
> die Quere.
Bislang gehe ich davon aus, das alles zu Fuß auf der Kommandozeile zu
machen. Jedenfalls ist mir nicht bewusst, irgendeine Automatik benutzt
zu haben, aber man weiß ja nie, was SUSE da alles gestrickt hat, was ich
nur noch nicht kenne.
--
Gruß
Alex
Paul Muster
May 8, 2023, 11:03:06 AM5/8/23
to
Am 08.05.2023 um 16:01 schrieb Alexander Goetzenstein:
> Umgekehrt meine ich mich auch daran
> zu erinnern (ist schon etwas her), dass auch eine neu gesetzte Sperre in
> der Fritz!Box erst wirkung zeigte, nachdem der Server neu gestartet
> wurde. Vielleicht triggert das ja etwas in der Fritz!Box? Falls dem so
> sein könnte: wie könnte man das triggern ohne Reboot?
Reagiert die Box auf das da?
> Umgekehrt meine ich mich auch daran
> zu erinnern (ist schon etwas her), dass auch eine neu gesetzte Sperre in
> der Fritz!Box erst wirkung zeigte, nachdem der Server neu gestartet
> wurde. Vielleicht triggert das ja etwas in der Fritz!Box? Falls dem so
> sein könnte: wie könnte man das triggern ohne Reboot?
ip link set dev <dev> down && sleep 10 && ip link set dev <dev> up
mfG Paul
Bernd Mayer
May 8, 2023, 3:09:14 PM5/8/23
to
Am 08.05.23 um 14:16 schrieb Alexander Goetzenstein:
hilft es, dhclient für Dein Netzwerkdevice aufzurufen?
https://linux.die.net/man/8/dhclient
Oder das Netzwerk insgesamt neu zu starten.
Bernd Mayer
> Hallo,
> hier habe ich einen Server unter openSUSE Tumbleweed, der im
> Normalbetrieb keine Routen ins böse Internet hat. Zudem sperrt die
> Kindersicherung und Profil in der Fritz!Box den Zugang nach außen.
>
> Wenn ich nun ein Update o.ä. vorhabe, setze ich die default route auf
> die Fritz!Box und schalte Kindersicherung aus und das Profil um (alles
> vorübergehend, versteht sich). Trotzdem erhält der Server keine
> Verbindung nach draußen:
>
>> # ping -c 4 8.8.8.8
>> PING 8.8.8.8 (8.8.8.8) 56(84) Bytes an Daten.
>> Von 192.168.221.5 icmp_seq=1 Zielhost nicht erreichbar
>
> hier habe ich einen Server unter openSUSE Tumbleweed, der im
> Normalbetrieb keine Routen ins böse Internet hat. Zudem sperrt die
> Kindersicherung und Profil in der Fritz!Box den Zugang nach außen.
>
> Wenn ich nun ein Update o.ä. vorhabe, setze ich die default route auf
> die Fritz!Box und schalte Kindersicherung aus und das Profil um (alles
> vorübergehend, versteht sich). Trotzdem erhält der Server keine
> Verbindung nach draußen:
>
>> # ping -c 4 8.8.8.8
>> PING 8.8.8.8 (8.8.8.8) 56(84) Bytes an Daten.
>> Von 192.168.221.5 icmp_seq=1 Zielhost nicht erreichbar
>
> Das ändert sich leider erst nach einem Reboot. Da dieser vorliegend
> recht aufwendig ist, würde ich mir den gerne sparen. Wie kann ich mich
> der Ursache und damit der Lösung nähern?
Hallo,
> recht aufwendig ist, würde ich mir den gerne sparen. Wie kann ich mich
> der Ursache und damit der Lösung nähern?
hilft es, dhclient für Dein Netzwerkdevice aufzurufen?
https://linux.die.net/man/8/dhclient
Oder das Netzwerk insgesamt neu zu starten.
Bernd Mayer
Alexander Goetzenstein
May 9, 2023, 6:24:44 AM5/9/23
to
Hallo,
Am 08.05.23 um 21:09 schrieb Bernd Mayer:
> Oder das Netzwerk insgesamt neu zu starten.
Danke für den Anstoß:
systemctl restart network
funktioniert.
--
Gruß
Alex
Am 08.05.23 um 21:09 schrieb Bernd Mayer:
>
> hilft es, dhclient für Dein Netzwerkdevice aufzurufen?
da DHCP nicht verwendet wird, hilft es nicht.
> hilft es, dhclient für Dein Netzwerkdevice aufzurufen?
> Oder das Netzwerk insgesamt neu zu starten.
systemctl restart network
funktioniert.
--
Gruß
Alex
Alexander Goetzenstein
May 9, 2023, 6:27:55 AM5/9/23
to
Hallo,
Am 08.05.23 um 16:43 schrieb Paul Muster:
Danke, aber leider nicht. Doch systemctl restart network hilft (siehe
nebenan).
--
Gruß
Alex
Am 08.05.23 um 16:43 schrieb Paul Muster:
nebenan).
--
Gruß
Alex
Andreas Kohlbach
May 9, 2023, 10:39:47 PM5/9/23
to
On Tue, 9 May 2023 12:24:35 +0200, Alexander Goetzenstein wrote:
>
> Am 08.05.23 um 21:09 schrieb Bernd Mayer:
>>
>> hilft es, dhclient für Dein Netzwerkdevice aufzurufen?
>
> da DHCP nicht verwendet wird, hilft es nicht.
Hast Du eine /etc/NetworkManager/system-connections/Auto\ Ethernet.nmconnection
>
> Am 08.05.23 um 21:09 schrieb Bernd Mayer:
>>
>> hilft es, dhclient für Dein Netzwerkdevice aufzurufen?
>
> da DHCP nicht verwendet wird, hilft es nicht.
oder ähnlich?
Dort (auch für WLAN-Verbindungen) kannst Du IP hart vernageln. Ich habe
dort u.a.
[ipv4]
address1=192.168.0.101/24,192.168.0.1
dns=192.168.0.1;4.2.2.1;8.8.8.8;
dns-search=
method=manual
Mir kommt aber eben die "/24" doch seltsam vor, auch wenn es so
funktioniert. Von Hand hatte ich die Datei IIRC nicht editiert, sondern
über entsprechende GUI in MATE.
>> Oder das Netzwerk insgesamt neu zu starten.
>
> Danke für den Anstoß:
> systemctl restart network
> funktioniert.
--
Andreas
0 new messages