înregistrare Logare
Puncte:0
avatar Server

Rutarea nu funcționează corect când sunt conectate două NIC

drapel jp
user2181884

Executăm un server cu o placă PCIe Gigabit Ethernet cu 2 porturi NetXtreme BCM5720. Acesta are două porturi, pe care fiecare le mapează la diferite id-uri fizice și nume logice;

sudo lshw -class network
  *-rețea:0               
       descriere: interfață Ethernet
       produs: NetXtreme BCM5720 PCIe Gigabit Ethernet cu 2 porturi
       furnizor: Broadcom Inc. și filiale
       ID fizic: 0
       info autobuz: pci@0000:04:00.0
       nume logic: eno1
       versiunea: 00
       serial: b8:cb:29:97:26:61
       dimensiune: 1 Gbit/s
       capacitate: 1 Gbit/s
       lățime: 64 biți
       ceas: 33 MHz
       capabilități: pm vpd msi msix pciexpress bus_master cap_list rom ethernet fizic tp 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configurație: autonegotiation=on broadcast=da driver=tg3 driverversion=3.137 duplex=firmware complet=FFV21.81.3 bc 5720-v1.39 ip=192.168.1.211 latency=0 link=da multicast=da port=twisted pair speed=1Gbit s
       resurse: irq:17 memorie:91930000-9193ffff memorie:91940000-9194ffff memorie:91950000-9195ffff memorie:91d00000-91d3ffff
  *-rețea:1
       descriere: interfață Ethernet
       produs: NetXtreme BCM5720 PCIe Gigabit Ethernet cu 2 porturi
       furnizor: Broadcom Inc. și filiale
       ID fizic: 0.1
       info autobuz: pci@0000:04:00.1
       nume logic: eno2
       versiunea: 00
       serial: b8:cb:29:97:26:62
       dimensiune: 1 Gbit/s
       capacitate: 1 Gbit/s
       lățime: 64 biți
       ceas: 33 MHz
       capabilități: pm vpd msi msix pciexpress bus_master cap_list rom ethernet fizic tp 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configurație: autonegotiation=on broadcast=da driver=tg3 driverversion=3.137 duplex=firmware complet=FFV21.81.3 bc 5720-v1.39 ip=192.168.3.201 latency=0 link=da multicast=da port=twisted pair speed=1Gbit s
       resurse: irq:18 memorie:91900000-9190ffff memorie:91910000-9191ffff memorie:91920000-9192ffff memorie:91d40000-91d7ffff

După cum se arată în rezultat, le sunt date IP-uri pe diferite subrețele.

Subrețeaua 192.168.3 este orientată spre exterior, în timp ce 192.168.1 este doar intern. Am configurat redirecționarea portului în routerul nostru astfel încât traficul de intrare către porturile 80 și 443 să ajungă la 192.168.3.201 Intenția este de a rula aplicații web pe acel server, lăsând ssh-ul deschis în rețeaua internă pentru întreținere.

Funcționează... parțial

Pentru a testa, rulăm imaginea implicită nginx docker

docker run -d -p 192.168.3.201:80:80 -p 192.168.3.201:443:443 --restart=dacă nu este oprit nginx:latest

Inițial, NU putem accesa interfața web din exterior. Totuși, dacă tragem cablul ethernet la eno0, funcționează brusc. Ceea ce mă deranjează cu adevărat este că de fapt continuă să funcționeze atunci când conectez din nou eno0.

Acest lucru este foarte reproductibil. După repornirea sistemului, nu funcționează, dar deconectarea / reconectarea eno0 și brusc funcționează din nou.

Ce ne lipsește?

Adăugarea de ieșire a rutei IP conform sugestiei de JFL; la rebot;

implicit prin 192.168.1.1 dev eno1 proto dhcp src 192.168.1.211 metric 100 
implicit prin 192.168.3.1 dev eno2 proto dhcp src 192.168.3.201 metric 100 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.211 
192.168.1.1 dev eno1 proto dhcp scope link src 192.168.1.211 metric 100 
192.168.3.0/24 dev eno2 proto kernel scope link src 192.168.3.201 
192.168.3.1 dev eno2 proto dhcp scope link src 192.168.3.201 metric 100

La deconectarea eno0;

implicit prin 192.168.3.1 dev eno2 proto dhcp src 192.168.3.201 metric 100 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.3.0/24 dev eno2 proto kernel scope link src 192.168.3.201 
192.168.3.1 dev eno2 proto dhcp scope link src 192.168.3.201 metric 100

După reconectarea eno0

implicit prin 192.168.3.1 dev eno2 proto dhcp src 192.168.3.201 metric 100 
implicit prin 192.168.1.1 dev eno1 proto dhcp src 192.168.1.211 metric 100 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.211 
192.168.1.1 dev eno1 proto dhcp scope link src 192.168.1.211 metric 100 
192.168.3.0/24 dev eno2 proto kernel scope link src 192.168.3.201 
192.168.3.1 dev eno2 proto dhcp scope link src 192.168.3.201 metric 100
49
0 + 0
JFL avatar
drapel pk
JFL
Puteți adăuga ieșirea „ip route” înainte și după deconectare/reconectare?
2
Răspunde
Puncte:0
JFL avatar Server
drapel pk
JFL

problema dvs. este că ați configurat un gateway pe ambele interfețe, după cum arată:

implicit prin 192.168.1.1 dev eno1 proto dhcp src 192.168.1.211 metric 100 
implicit prin 192.168.3.1 dev eno2 proto dhcp src 192.168.3.201 metric 100

Ambele au aceeași măsurătoare, așa că sistemul trebuie să aleagă una. Modul în care se face această alegere depinde de sistemul de operare utilizat.

Indiferent de criteriile pe care le folosește sistemul de operare, acesta selectează ruta care iese prin interfața eno1 la pornire, astfel încât traficul să nu fie trimis pe Internet.

Când deconectați NIC-ul, rămâne doar un gateway (cel corect), așa că funcționează.

Faptul că încă funcționează după ce reconectați eno1 arată că sistemul de operare probabil folosește cea mai „veche” rută (puteți vedea că ordinea acestor două rute este inversată după reconectare).

Pentru a remedia acest lucru, trebuie să eliminați gateway-ul implicit de pe NIC-ul intern și, dacă este necesar, să îl înlocuiți cu rute către rețeaua internă. Dacă nu aveți altă rețea internă decât 192.168.1.X/X, atunci nu aveți nevoie de acele rute.

Deoarece utilizați DHCP, trebuie să eliminați setarea „router” din domeniul 192.168.3.X/X sau să utilizați o adresă IP statică (dacă trebuie să lăsați opțiunea de router pentru alte gazde).

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

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.