|
SvenL76
Anmeldungsdatum:
16. Januar 2022
Beiträge: 14
|
Hallo zusammen, ich hoffe, ich bin hier richtig. Ich weiss ehrlich gesagt noch nicht, wo ich genau suchen soll bzw. welche Daten man braucht, um den Fehler zu finden. Also, mein Problem: Ich habe einen virtuellen Server mit einer 20.04 minimal Installation. Auf diesem habe ich unser Familien-DMS System laufen. Da wir den Server nur in der Familie nutzen habe ich mit UFW den Zugriff von außen abgeriegelt - mit Ausnahme des SSH-Zugriffs auf Port 21. Der Server hat (natürlich) eine feste IP. Mit VPNC hab ich es jetzt so eingerichtet, dass der Server sich mit unser heimischen Fritz-Box verbindet. Über die dort vergebene IP ist nun, wie gewünscht, das DMS verfügbar, dazu noch ein Pfad einer SMB-Freigabe, die das DMS benötigt. Das alles läuft soweit ganz stabil. Da Fritz die Verbindungen wohl gerne bei Inaktivität trennt, hab ich das System veranlasst, via Cron einmal stündlich die Verbindung neu aufzubauen. Auch das funktioniert einwandfrei (auch wenn es nicht elegant ist, aber ein funktionierende workaround). Nun zum Problem: Mein Provider zuhause vollzieht noch die tägliche Zwangstrennung. Ich habe die Fritz daher veranlasst, zwischen 4 und 5 Uhr eine geplante Zwangstrennung vorzunehmen. Hiermit scheint das System aber ein Problem zu haben. Nach der Zwangstrennung baut sich keine VPN-Verbindung mehr auf. Auch kann ich auf den Server nicht mehr via SSH zugreifen (auch nicht über die öffentliche IP). Im Systemlog sehe ich, dass der Server aber läuft, erführt u.a. auch weiter die Crons aus. Jetzt hab ich gedacht, dass es vielleicht an der Trennung durch die Fritz liegt. Daher lasse ich den Server nun um 4 Uhr via VPNC-Disconnect die Verbindung trennen und erst 5 Uhr wieder aufbauen. Aber: Gleiches Problem. Beim "spielen" hab ich eben mehrfach den Fehler auch durch ein manuelles vpnc-disconnect reproduzieren können. Der Server ist jedes mal wie oben beschrieben nicht mehr ansprechbar, läuft aber weiter. Den Zugriff bekomme ich erst nach einem Serverneustart. Ich hab keine Idee wo ich suchen soll. Kann jemand helfen? Danke! Sven
Moderiert von DJKUhpisse: verschoben und Version angepasst
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 13293
|
SvenL76 schrieb: ... mit Ausnahme des SSH-Zugriffs auf Port 21. Der Server hat (natürlich) eine feste IP. Auch kann ich auf den Server nicht mehr via SSH zugreifen (auch nicht über die öffentliche IP). Im Systemlog sehe ich, dass der Server aber läuft, erführt u.a. auch weiter die Crons aus.
Wenn der Zugriff via SSH nicht funktioniert, kannst Du den Server per ping (icmp) oder per Portscan (Ports 22 und 21?) noch erreichen? Oder hast Du icmp auch blockiert? Benutzt Du SSH (für den Zugriff auf den Server) im VPN oder via Internet? Poste vom Server die Ausgabe von:
sudo iptables -nvx -L
|
|
kB
Supporter, Wikiteam
Anmeldungsdatum:
4. Oktober 2007
Beiträge: 7816
|
SvenL76 schrieb: […] virtuellen Server mit einer 20.04 minimal Installation
Hast Du diesen mit dem Server-ISO-Image oder mit einem Desktop-ISO-Image installiert?
[…] Familien-DMS System
Was auch immer das sein mag.
[…] mit UFW den Zugriff von außen abgeriegelt
Funktioniert es denn ohne UFW wunschgemäß?
[…] Zwangstrennung
Funktioniert es dann nach VPNC-disconnect/-connect wunschgemäß? Zeige bitte die Netzwerkkonfiguration jeweils vor/während/nach VPNC-Verbindung:
ip addr
ip route
ls -l /etc/resolv.conf
cat /etc/resolv.conf
|
|
SvenL76
(Themenstarter)
Anmeldungsdatum:
16. Januar 2022
Beiträge: 14
|
Hast Du diesen mit dem Server-ISO-Image oder mit einem Desktop-ISO-Image installiert?
Ich habe eine "fertige" Installation des Serveranbieters genommen. Ich gehe fest davon aus, dass es sich um die Server-Version handelt.
[…] Familien-DMS System
Was auch immer das sein mag.
Eine untechnische Forumulierung. Auf dem Server läuft die Server-Instanz des Dokumenten-Management-Systems EcoDMS (Version 18, APO).
Funktioniert es denn ohne UFW wunschgemäß?
Nein, kein Unterschied.
Funktioniert es dann nach VPNC-disconnect/-connect wunschgemäß?
Das hatte ich ja oben schon beschrieben. Meistens ja, teilweise nein. In diversen Fällen tritt der Fehler eben nicht nur nachts auf, sondern auch nach einem vpnc-disconnect. Ich schicke hier jetzt nal die gewünschten Ausgaben - allerdings natürlich nur in den Fällen, in denen das Problem nicht auftritt. Ansonsten komme ich ja nicht mehr auf den Server zum abrufen. Vor der Verbindung: root@v71023:~# ip addr
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
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/void
inet 127.0.0.1/32 scope host venet0
valid_lft forever preferred_lft forever
inet 195.90.201.179/24 brd 195.90.201.255 scope global venet0:0
valid_lft forever preferred_lft forever
root@v71023:~# ip route
default dev venet0 scope link
195.90.201.0/24 dev venet0 proto kernel scope link src 195.90.201.179
root@v71023:~# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 34 Jan 14 04:52 /etc/resolv.conf -> ../run/systemd/resolv e/resolv.conf
root@v71023:~# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 178.254.16.141
nameserver 178.254.16.151Während der Verbindung:
root@v71023:~# ip addr
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
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/void
inet 127.0.0.1/32 scope host venet0
valid_lft forever preferred_lft forever
inet 195.90.201.179/24 brd 195.90.201.255 scope global venet0:0
valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1412 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 192.168.33.223/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::48fd:afd7:331b:1819/64 scope link stable-privacy
valid_lft forever preferred_lft forever
root@v71023:~# ip route
default dev tun0 scope link
37.131.181.20 dev venet0 scope link src 195.90.201.179
195.90.201.0/24 dev venet0 proto kernel scope link src 195.90.201.179
root@v71023:~# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 34 Jan 14 04:52 /etc/resolv.conf -> ../run/systemd/resolve/resolv.conf
root@v71023:~# cat /etc/resolv.conf
#@VPNC_GENERATED@ -- this file is generated by vpnc
# and will be overwritten by vpnc
# as long as the above mark is intact
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 192.168.33.1Und nach dem Abbau:
root@v71023:~# ip addr
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
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/void
inet 127.0.0.1/32 scope host venet0
valid_lft forever preferred_lft forever
inet 195.90.201.179/24 brd 195.90.201.255 scope global venet0:0
valid_lft forever preferred_lft forever
root@v71023:~# ip route
default dev venet0 scope link
195.90.201.0/24 dev venet0 proto kernel scope link src 195.90.201.179
root@v71023:~# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 34 Jan 14 04:52 /etc/resolv.conf -> ../run/systemd/resolve/resolv.conf
root@v71023:~# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 178.254.16.141
nameserver 178.254.16.151vielen Dank schonmal !
|
|
SvenL76
(Themenstarter)
Anmeldungsdatum:
16. Januar 2022
Beiträge: 14
|
lubux schrieb:
Wenn der Zugriff via SSH nicht funktioniert, kannst Du den Server per ping (icmp) oder per Portscan (Ports 22 und 21?) noch erreichen?
Erstmal muss ich mich korrigieren, ich habe natürlich Port 22 für SSH offen, nicht 21. Und nein, der Server reagiert auf seiner öffentlichen IP nicht mehr auf einen PING. Und auch der Portscanner zeigt den 22 als DOWN an ohne Rückmeldung. Läuft der Server "normal" reagiert er sowohl auf den PING als auch den Portscan auf 22.
Oder hast Du icmp auch blockiert? Benutzt Du SSH (für den Zugriff auf den Server) im VPN oder via Internet?
Nicht dass ich wüsste - aber wie gesagt, er reagiert normalerweise. SSH kann ich theoretisch über beide Wege nutzen, nehme aber in der Regel den über die öffentliche IP, weil die Verbindung stabiler ist.
Poste vom Server die Ausgabe von sudo iptables -nvx -L
Chain INPUT (policy DROP 107 packets, 4738 bytes)
pkts bytes target prot opt in out source dest ination
11216 7413928 ufw-before-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
11216 7413928 ufw-before-input all -- * * 0.0.0.0/0 0.0.0.0/0
161 12400 ufw-after-input all -- * * 0.0.0.0/0 0.0.0.0/0
107 4738 ufw-after-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
107 4738 ufw-reject-input all -- * * 0.0.0.0/0 0.0.0.0/0
107 4738 ufw-track-input all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 1 packets, 40 bytes)
pkts bytes target prot opt in out source dest ination
1 40 ufw-before-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0
1 40 ufw-before-forward all -- * * 0.0.0.0/0 0.0.0.0/0
1 40 ufw-after-forward all -- * * 0.0.0.0/0 0.0.0.0/0
1 40 ufw-after-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0
1 40 ufw-reject-forward all -- * * 0.0.0.0/0 0.0.0.0/0
1 40 ufw-track-forward all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source dest ination
10986 7423469 ufw-before-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
10986 7423469 ufw-before-output all -- * * 0.0.0.0/0 0.0.0.0/0
57 9275 ufw-after-output all -- * * 0.0.0.0/0 0.0.0.0/0
57 9275 ufw-after-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
57 9275 ufw-reject-output all -- * * 0.0.0.0/0 0.0.0.0/0
57 9275 ufw-track-output all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-after-forward (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-after-input (1 references)
pkts bytes target prot opt in out source dest ination
32 3000 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
19 4506 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
0 0 ufw-skip-to-policy-input tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
3 156 ufw-skip-to-policy-input tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
0 0 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:68
0 0 ufw-skip-to-policy-input all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
Chain ufw-after-logging-forward (1 references)
pkts bytes target prot opt in out source dest ination
1 40 LOG all -- * * 0.0.0.0/0 0.0.0. 0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "
Chain ufw-after-logging-input (1 references)
pkts bytes target prot opt in out source dest ination
72 3130 LOG all -- * * 0.0.0.0/0 0.0.0. 0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "
Chain ufw-after-logging-output (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-after-output (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-before-forward (1 references)
pkts bytes target prot opt in out source dest ination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0. 0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0. 0/0 icmptype 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0. 0/0 icmptype 11
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0. 0/0 icmptype 12
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0. 0/0 icmptype 8
1 40 ufw-user-forward all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-before-input (1 references)
pkts bytes target prot opt in out source dest ination
9750 7296294 ACCEPT all -- lo * 0.0.0.0/0 0.0.0. 0/0
1181 96294 ACCEPT all -- * * 0.0.0.0/0 0.0.0. 0/0 ctstate RELATED,ESTABLISHED
12 4264 ufw-logging-deny all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
12 4264 DROP all -- * * 0.0.0.0/0 0.0.0. 0/0 ctstate INVALID
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0. 0/0 icmptype 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0. 0/0 icmptype 11
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0. 0/0 icmptype 12
1 60 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0. 0/0 icmptype 8
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0. 0/0 udp spt:67 dpt:68
272 17016 ufw-not-local all -- * * 0.0.0.0/0 0. 0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0 224.0. 0.251 udp dpt:5353
0 0 ACCEPT udp -- * * 0.0.0.0/0 239.25 5.255.250 udp dpt:1900
272 17016 ufw-user-input all -- * * 0.0.0.0/0 0 .0.0.0/0
Chain ufw-before-logging-forward (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-before-logging-input (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-before-logging-output (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-before-output (1 references)
pkts bytes target prot opt in out source dest ination
9750 7296294 ACCEPT all -- * lo 0.0.0.0/0 0.0.0. 0/0
1179 117900 ACCEPT all -- * * 0.0.0.0/0 0.0.0. 0/0 ctstate RELATED,ESTABLISHED
57 9275 ufw-user-output all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-logging-allow (0 references)
pkts bytes target prot opt in out source dest ination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0. 0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW ALLOW] "
Chain ufw-logging-deny (2 references)
pkts bytes target prot opt in out source dest ination
12 4264 RETURN all -- * * 0.0.0.0/0 0.0.0. 0/0 ctstate INVALID limit: avg 3/min burst 10
0 0 LOG all -- * * 0.0.0.0/0 0.0.0. 0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "
Chain ufw-not-local (1 references)
pkts bytes target prot opt in out source dest ination
221 9510 RETURN all -- * * 0.0.0.0/0 0.0.0. 0/0 ADDRTYPE match dst-type LOCAL
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0. 0/0 ADDRTYPE match dst-type MULTICAST
51 7506 RETURN all -- * * 0.0.0.0/0 0.0.0. 0/0 ADDRTYPE match dst-type BROADCAST
0 0 ufw-logging-deny all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10
0 0 DROP all -- * * 0.0.0.0/0 0.0.0. 0/0
Chain ufw-reject-forward (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-reject-input (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-reject-output (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-skip-to-policy-forward (0 references)
pkts bytes target prot opt in out source dest ination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0. 0/0
Chain ufw-skip-to-policy-input (7 references)
pkts bytes target prot opt in out source dest ination
54 7662 DROP all -- * * 0.0.0.0/0 0.0.0. 0/0
Chain ufw-skip-to-policy-output (0 references)
pkts bytes target prot opt in out source dest ination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0. 0/0
Chain ufw-track-forward (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-track-input (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-track-output (1 references)
pkts bytes target prot opt in out source dest ination
1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0. 0/0 ctstate NEW
56 9215 ACCEPT udp -- * * 0.0.0.0/0 0.0.0. 0/0 ctstate NEW
Chain ufw-user-forward (1 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-user-input (1 references)
pkts bytes target prot opt in out source dest ination
109 4536 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:22
0 0 ACCEPT all -- * * 192.168.33.0/24 0.0.0. 0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:17001
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0. 0/0 udp dpt:17001
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:80
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0. 0/0 udp dpt:80
2 80 DROP tcp -- * * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:443
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0. 0/0 udp dpt:443
Chain ufw-user-limit (0 references)
pkts bytes target prot opt in out source dest ination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0. 0/0 limit: avg 3/min burst 5 LOG flags 0 level 4 prefix "[UFW LIMIT B LOCK] "
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0. 0/0 reject-with icmp-port-unreachable
Chain ufw-user-limit-accept (0 references)
pkts bytes target prot opt in out source dest ination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0. 0/0
Chain ufw-user-logging-forward (0 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-user-logging-input (0 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-user-logging-output (0 references)
pkts bytes target prot opt in out source dest ination
Chain ufw-user-output (1 references)
pkts bytes target prot opt in out source dest inationGrüße
Sven
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 13293
|
SvenL76 schrieb: Und nein, der Server reagiert auf seiner öffentlichen IP nicht mehr auf einen PING. Und auch der Portscanner zeigt den 22 als DOWN an ohne Rückmeldung. Läuft der Server "normal" reagiert er sowohl auf den PING als auch den Portscan auf 22. ..., nehme aber in der Regel den über die öffentliche IP, weil die Verbindung stabiler ist.
Hast Du evtl. die Möglichkeit, wenn der Port 22 von deinem eigenen Internetanschluss nicht mehr erreichbar ist, den Portscan (auf Port 22) von einem fremden Internetanschluss zu machen oder aus dem Internet mit einem geeigneten web-tool (z. B. via Mobilfunk oder gleichwertig) zu machen? EDIT: ich kann deinen Server auch scannen. Wenn Du die Möglichkeit jetzt hast, dann: Beim "spielen" hab ich eben mehrfach den Fehler auch durch ein manuelles vpnc-disconnect reproduzieren können. Der Server ist jedes > mal wie oben beschrieben nicht mehr ansprechbar, läuft aber weiter. Den Zugriff bekomme ich erst nach einem Serverneustart.
damit ich den Portscan machen kann. BTW: Bei welchem Provider hast Du deinen Internetanschluss?
|
|
SvenL76
(Themenstarter)
Anmeldungsdatum:
16. Januar 2022
Beiträge: 14
|
Hast Du evtl. die Möglichkeit, wenn der Port 22 von deinem eigenen Internetanschluss nicht mehr erreichbar ist, den Portscan (auf Port 22) von einem fremden Internetanschluss zu machen oder aus dem Internet mit einem geeigneten web-tool (z. B. via Mobilfunk oder gleichwertig) zu machen?
Ja, ich hab mehrere versucht. Online-Tool und Zugriff aus dem Büro. ich kann deinen Server auch scannen. Wenn Du die Möglichkeit jetzt hast, dann: Beim "spielen" hab ich eben mehrfach den Fehler auch durch ein manuelles vpnc-disconnect reproduzieren können. Der Server ist jedes > mal wie oben beschrieben nicht mehr ansprechbar, läuft aber weiter. Den Zugriff bekomme ich erst nach einem Serverneustart.
damit ich den Portscan machen kann.
Gerne. Ich habs eben versucht, heute reagiert er auf manuelles abbauen ohne Probleme. Ich geb Bescheid wenn er wieder hängt und lasse ihn mal
BTW: Bei welchem Provider hast Du deinen Internetanschluss?
Lichtwelle Erkrath. Ich hätte folgende Idee - vielleicht ist die aber auch ganz falsch: Ich hab nochmal geschaut, was die Fritzbox sagt. Heute Nacht hat der Server brav zu jeder vollen Stunde die Verbindung aufgebaut. Um 4 Uhr habe ich den Server dann abbauen lassen, damit die Zwangstrennung vollzogen werden kann. Ab 6 Uhr sollte er neu verbinden. Das Cron ist auch einmal die Stunde gelaufen, sagt das Syslog. Kann es sein, dass es irgendein Problem mit der dynamischen Adresse der Fritz-Box gibt? Bzw. dass der Server hier mit der Änderung der IP ein Problem hat? Der Absturz tritt zuverlässig immer auf, wenn nach der Zwangstrennung neu verbunden werden soll.
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 13293
|
SvenL76 schrieb: Kann es sein, dass es irgendein Problem mit der dynamischen Adresse der Fritz-Box gibt? Bzw. dass der Server hier mit der Änderung der IP ein Problem hat?
Du meinst mit dyndns? Welchen dyndns-Provider hast Du? Ein Problem mit dyndns sollte aber keine Auswirkungen auf die Erreichbarkeit des Servers, per ssh aus dem Internet, haben. Denn das ist unabhängig von der VPN-Verbindung. Es sei den der cronjob (zum herstellen der VPN-Verbindung) ist so "fehlerhaft" , dass der Server auch mit ssh ein Problem bekommt. Poste mal den Eintrag in der crontab.
|
|
SvenL76
(Themenstarter)
Anmeldungsdatum:
16. Januar 2022
Beiträge: 14
|
Du meinst mit dyndns? Welchen dyndns-Provider hast Du und welchen dyndns-Client hast Du auf dem Server?
Ich meinte es anders herum, die Fritz ist ja nur per DynDNS erreichbar. Die macht das über den eigenen Fritz-Dienst. Ein Problem mit dyndns sollte aber keine Auswirkungen auf die Erreichbarkeit des Servers, per ssh aus dem Internet, haben. Denn das ist unabhängig von der VPN-Verbindung. Es sei den der cronjob (zum herstellen der VPN-Verbindung) ist so "fehlerhaft" , dass der Server auch mit ssh ein Problem bekommt. Poste mal den Eintrag in der crontab.
Das ist der "Test"-Con, der heute nacht bis 4 stündlich aufbauen, um 4 abbauen, um 6 wieder aufbauen sollte. 0 1 * * * /usr/sbin/vpnc fritz > /tmp/cronoutput.log
0 2 * * * /usr/sbin/vpnc fritz > /tmp/cronoutput.log
0 3 * * * /usr/sbin/vpnc fritz > /tmp/cronoutput.log
0 4 * * * /usr/sbin/vpnc-disconnect > /tmp/cronoutput.log
0 6 * * * /usr/sbin/vpnc fritz > /tmp/cronoutput.log
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 13293
|
SvenL76 schrieb: ... per DynDNS erreichbar. Die macht das über den eigenen Fritz-Dienst.
Ja, das könnte das Problem sein. Ich habe mit MyFritz schlechte Erfahrungen gemacht und benutze es nicht mehr. Such dir einen geeigneten und zuverlässigen dyndns-Provider und deaktiviere den MyFritz-Dienst. Auf dem Server könntest Du mit dem cronjob zum herstellen der VPN-Verbindung auch ein Script benutzen, das die Erreichbarkeit (z. B. den Rückgabewert eines Portscans) deiner FritzBox via dyndns testet und wenn die OK ist, erst dann versuch die VPN-Verbindung herzustellen.
|
|
kB
Supporter, Wikiteam
Anmeldungsdatum:
4. Oktober 2007
Beiträge: 7816
|
SvenL76 schrieb: […] Meistens ja, teilweise nein. In diversen Fällen tritt der Fehler eben nicht nur nachts auf, sondern auch nach einem vpnc-disconnect. Ich schicke hier jetzt nal die gewünschten Ausgaben - allerdings natürlich nur in den Fällen, in denen das Problem nicht auftritt. Ansonsten komme ich ja nicht mehr auf den Server zum abrufen.
Natürlich wären diese Informationen gerade im Fall, wenn das Problem auftritt, interessant. Da der Server ja weiter läuft, kannst Du die Informationen in einer Datei speichern und nach der Reparatur abfragen. Im Normalfall zeigt sich hier nur eine Merkwürdigkeit:
root@v71023:~# ip addr
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
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/void
inet 127.0.0.1/32 scope host venet0
valid_lft forever preferred_lft forever
inet 195.90.201.179/24 brd 195.90.201.255 scope global venet0:0
valid_lft forever preferred_lft forever
Warum hast Du diese IP-Adresse aus dem lokalen Block an die Schnittstelle venet0 gebunden? Das macht für mich gar keinen Sinn. Obwohl dies wohl nicht die Ursache für das Problem sein wird, würde ich diese IP-Adresse löschen.
|
|
SvenL76
(Themenstarter)
Anmeldungsdatum:
16. Januar 2022
Beiträge: 14
|
lubux schrieb: ... per DynDNS erreichbar. Die macht das über den eigenen Fritz-Dienst.
Ja, das könnte das Problem sein. Ich habe mit MyFritz schlechte Erfahrungen gemacht und benutze es nicht mehr. Such dir einen geeigneten und zuverlässigen dyndns-Provider und deaktiviere den MyFritz-Dienst. Auf dem Server könntest Du mit dem cronjob zum herstellen der VPN-Verbindung auch ein Script benutzen, das die Erreichbarkeit (z. B. den Rückgabewert eines Portscans) deiner FritzBox via dyndns testet und wenn die OK ist, erst dann versuch die VPN-Verbindung herzustellen.
Ich habe jetzt auf einen "professionellen" Anbieter umgestellt und die Konfiguration im Server angepasst. Ändert aber nichts an der Problematik..
|
|
SvenL76
(Themenstarter)
Anmeldungsdatum:
16. Januar 2022
Beiträge: 14
|
kB schrieb: SvenL76 schrieb: […] Meistens ja, teilweise nein. In diversen Fällen tritt der Fehler eben nicht nur nachts auf, sondern auch nach einem vpnc-disconnect. Ich schicke hier jetzt nal die gewünschten Ausgaben - allerdings natürlich nur in den Fällen, in denen das Problem nicht auftritt. Ansonsten komme ich ja nicht mehr auf den Server zum abrufen.
Natürlich wären diese Informationen gerade im Fall, wenn das Problem auftritt, interessant. Da der Server ja weiter läuft, kannst Du die Informationen in einer Datei speichern und nach der Reparatur abfragen.
ok, ich probiere mal morgens die Abfrage via Cron zu machen.
Im Normalfall zeigt sich hier nur eine Merkwürdigkeit:
Warum hast Du diese IP-Adresse aus dem lokalen Block an die Schnittstelle venet0 gebunden? Das macht für mich gar keinen Sinn. Obwohl dies wohl nicht die Ursache für das Problem sein wird, würde ich diese IP-Adresse löschen.
Ich bin gänzlich unschuldig ☺ Das scheint so standardmäßig konfiguriert zu sein - jedenfalls hab ich nichts eingestellt und im VPNc finde ich hierzu auch nichts.
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 13293
|
SvenL76 schrieb: Ich habe jetzt auf einen "professionellen" Anbieter umgestellt und die Konfiguration im Server angepasst. Ändert aber nichts an der Problematik..
Alternativ zu VPNC mit der FritzBox, könntest Du einen PI an der FritzBox und WireGuard, auf deinem vServer bzw. PI benutzen. Bis die FritzBox auch WireGuard hat/kann, dauert es m. E. evtl. noch 2 bis 3 AVM-Firmwware-Versionen. 😉
|
|
SvenL76
(Themenstarter)
Anmeldungsdatum:
16. Januar 2022
Beiträge: 14
|
lubux schrieb: SvenL76 schrieb: Ich habe jetzt auf einen "professionellen" Anbieter umgestellt und die Konfiguration im Server angepasst. Ändert aber nichts an der Problematik..
Alternativ zu VPNC mit der FritzBox, könntest Du einen PI an der FritzBox und WireGuard, auf deinem vServer bzw. PI benutzen. Bis die FritzBox auch WireGuard hat/kann, dauert es m. E. evtl. noch 2 bis 3 AVM-Firmwware-Versionen. 😉
Bevor es zu Off-Topic wird: Ich könnte eine openVPN zu einem Synology NAS im Netzwerk aufbauen. Allerdings bekommt er da als Client eine andere IP - wie bekomme ich denn dann aus dem Netzwerk zugriff auf den Server? Deshalb hab ich den Weg zur Fritz genommen, da ist der Client einfach nur ein Rechner im Netzwerk.
|