Puncte:1

Eroare intermitentă la conectarea SSH/HTTPS la VM Guest care rulează KVM pe Ubuntu 20.04 LTS - după trimiterea unui ping SSH/HTTPS funcționează

drapel cn

poster pentru prima dată.

Aveți o problemă ciudată cu eșecul intermitent, conectarea la SSH/HTTPS a unui VM invitat.

Cum se reproduce problema:

  1. Porniți gazda și invitatul, așteptați câteva ore.

  2. SSH/HTTPS în invitat din afara, fara conectivitate.

  3. SSH către oaspete de la gazdă funcționează întotdeauna.

  4. SSH la găzduire din afara funcționează întotdeauna

  5. Ping invitat de la din afara, apoi SSH/HTTPS către invitat din afara, funcționează întotdeauna

  6. Așteptați câteva ore, apoi SSH/HTTPS pentru oaspeți din afara - eșuează din nou.

Am încercat diverse lucruri pentru a vedea dacă aș putea găsi problema, dar niciuna dintre „remediile” propuse, pe care le-au postat alții, par să se potrivească situației mele și nu funcționează pentru problema mea.

Pregatirea:

Server Ubuntu 20.04 LTS cu qemu qemu-kvm libvirt-clients libvirt-daemon-system virtinst bridge-utils pe o mașină fizică cu 2 interfețe de rețea.

1 interfață bridge și 1 interfață conectate direct.

Interfața bridge este folosită pentru gazdă și invitat, interfața directă folosită pentru a doua interfață numai pentru oaspeți.

Invitatul este instalarea serverului Debian 11.1

Interfața bridge este conectată la un comutator standard neadministrat

IP-ul gazdei este 192.168.1.26/24 Gateway 192.168.1.254 IP-ul invitatului este 192.168.1.27/24 Gateway 192.168.1.254

A doua interfață conectată direct este setată la 192.168.10.1/24, fără gateway (Utilizat pentru VLAN).

Pentru a vă asigura că nu există niciun firewall care să interfereze cu accesul oaspeților, br_netfilter este activat și se încarcă următoarele:

net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-arptables=0

Unii indică faptul că ar putea fi problematic să ai o gazdă pe un IP în aceeași subrețea cu IP-ul oaspetelui. Trebuie să setez intrări suplimentare de rutare?

Alții sugerează probleme ARP cu adresele MAC.

Am setat adrese MAC fixe folosind cele din intervalul recomandat. Acest lucru este necesar deoarece partea din amonte de la acest oaspete va trebui să cunoască adresa MAC pentru controlul accesului de ieșire pentru gazdă și oaspete.

ip o ieșire pe gazdă:

eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br1 state UP group default qlen 1000
    link/ether 00:18:1c:04:04:5c brd ff:ff:ff:ff:ff:ff
 eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br2 state UP group default qlen 1000
    link/ether 00:18:1c:04:04:5d brd ff:ff:ff:ff:ff:ff
 br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stare UP grup implicit qlen 1000
    link/ether 00:18:1c:04:04:5c brd ff:ff:ff:ff:ff:ff
    inet 169.254.2.83/16 brd 169.254.255.255 scope link noprefixroute br1
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
 br2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stare UP grup implicit qlen 1000
    link/ether 00:18:1c:04:04:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.26/24 brd 192.168.1.255 scope global noprefixroute br2
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
 6: macvtap0@br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 500
    link/ether 52:54:00:e9:15:a1 brd ff:ff:ff:ff:ff:ff
 vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br2 state NECUNOSCUT grup implicit qlen 1000
    link/ether fe:54:00:e9:15:b2 brd ff:ff:ff:ff:ff:ff

Ieșire rută ip pe gazdă:

implicit prin 192.168.1.254 dev br2 proto metric static 425
169.254.0.0/16 dev br1 proto kernel scope link src 169.254.2.83 metric 426
192.168.1.0/24 dev br2 proto kernel scope link src 192.168.1.26 metric 425
224.0.0.0/4 dev br1 proto static scope link metric 426

ip o ieșire pe guest:

 enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:e9:15:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.1/24 brd 192.168.10.255 scope global enp1s0
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
 enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000
    link/ether 52:54:00:e9:15:b2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.27/24 brd 192.168.1.255 scope global enp2s0
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
 enp1s0.73@enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000
    link/ether 52:54:00:e9:15:a1 brd ff:ff:ff:ff:ff:ff

Ieșire rută ip pe oaspeți:

implicit prin 192.168.1.254 dev enp2s0 onlink
192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.27
192.168.10.0/24 dev enp1s0 proto kernel scope link src 192.168.10.1 

Această problemă mi-a transformat părul mai gri decât era - mi-am petrecut câteva zile citind toate lucrurile posibile pe care ar fi putut să le fi ratat, dar nu am găsit nimic evident.

Orice indicații ar fi apreciate.

user535733 avatar
drapel cn
„*așteptați câteva ore*:” ați instalat o versiune desktop care poate intra în stare de repaus când este inactivă?
drapel cn
Fără desktop, doar server - în mod surprinzător, se pare că există o grămadă de oameni care au probleme similare, dar nu există o soluție evidentă

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.