De ce rezoluția DNS eșuează atunci când gateway-ul implicit este schimbat în circuitul de rezervă?

Avem o problemă ciudată cu care sper că cineva ne poate ajuta. Avem o clădire care are un circuit de fibră și un circuit de rezervă Comcast (coaxial).

Sistemul este configurat astfel:

Fibre NID (cablu cat6 la comutator) Comcast (cablu cat6 la comutator) | comutator negestionat | Unbuntu Linux Box ca router (cablu cat6 de la portul WAN la Switch) | Port LAN către fibră OLT | 4 porturi GPON de fibră care merg la multe ONT-uri

Am scris un script bash care va verifica în fiecare minut dacă gateway-ul principal (circuitul de fibră) este activat și dacă nu, va schimba gateway-ul implicit la routerul Comcast 10.1.10.1. Odată ce Gateway-ul principal revine, acesta va reveni automat la el.

Avem aceeași configurație în multe clădiri și funcționează perfect, dar avem câteva clădiri care odată ce gateway-ul implicit trece la circuitul de rezervă Comcast, DNS nu se va rezolva deloc de cele mai multe ori și uneori se va rezolva după cum 4 secunde la care majoritatea browserelor deja expiră.

Lucrul ciudat este că, dacă deconectam cablul de la OLT care merge la portul LAN al router-ului linux box, DNS-ul se rezolvă bine din linia de comandă de pe caseta linux și de la laptopul conectat la portul LAN al router-ului Linux box.

Dacă conectăm un laptop la un port rj45 de pe OLT, acesta primește în mod ciudat o adresă IPV6 (Comcast, chiar dacă ar fi să deconectam mai întâi routerul nostru Comcast). De aici, dacă deconectam porturile GPON de fibră care elimină rezidenții din ecuație, Backup Comcast se rezolvă corect și totul funcționează excelent și nu obținem o adresă ipv6 (folosim doar ipv4 pe partea lan). Conectați din nou porturile GPON de fibră pentru rezidenți și instantaneu DNS-ul nu se va mai rezolva.

OLT este setat cu izolarea portului, astfel încât rezidenții să nu se poată „vedea” între ei. Am încercat să setăm ACL-uri pentru a bloca tot traficul IPv6, precum și toate IPv4 private, nu pe subrețeaua 172.16.0.0/16, dar asta nu a funcționat.

/etc/resolv.conf

server de nume 8.8.8.8
server de nume 8.8.4.4
server de nume 1.1.1.1

/etc/resolv.conf este același, indiferent dacă este pe circuitul de rezervă sau pe circuitul principal.

/etc/network/interfaces

# Acest fișier descrie interfețele de rețea disponibile pe sistemul dumneavoastră
# și cum să le activezi. Pentru mai multe informații, consultați interfețe(5).

# Interfața de rețea loopback
auto lo
iface lo inet loopback


#Interfața de rețea LAN (portul din dreapta).
permit-hotplug enp2s0
iface enp2s0 inet static
    adresa 172.16.1.1
    mască de rețea 255.255.0.0

######## END LAN SETUP ###################################### #############

############ SETUP WAN PRINCIPALA ################################## #############
#WAN
permit-hotplug enp3s0
iface enp3s0 inet static
    adresa xxx.xxx.xxx.xxx
    mască de rețea 255.255.255.252
    gateway xxx.xxx.xxx.xxx
    servere de nume dns 8.8.8.8 8.8.4.4 1.1.1.1

########### TERMINAȚI Configurarea WAN PRINCIPALĂ
Circuit de rezervă #WAN
permit-hotplug enp3s0
iface enp3s0 inet dhcp
    servere de nume dns 8.8.8.8 8.8.4.4 1.1.1.1

####### TERMINARE BACKUP WAN SETUP FAILOVER ##################################

Am făcut un tcpdump, am văzut mai multe modemuri/routere „Comcast” pe partea LAN (am căutat adresele mac). Se pare că unii rezidenți au Comcast Internet și au conectat ONT-ul nostru la routerul lor Comcast și se scurge în sistem. Dacă setez un IP static de 10.0.0.xx și mă conectez la portul ONT rj45, pot face ping și pot naviga la modemul/routerul Comcast al cuiva. Odată ce am configurat ACL-urile, acest lucru este acum blocat, dar avem în continuare aceeași problemă.

Pentru a rezuma, se pare că există ceva (eventual modemuri/routere Comcast rezidenți) provenind de la unul sau mai mulți ONT-uri rezidenți care interferează cu rezoluția DNS, dar numai atunci când sistemul nostru a comutat gateway-ul implicit la routerul nostru de rezervă Comcast. Pentru a reitera acest lucru se întâmplă doar la două din multe clădiri cu aceeași configurație. La celelalte clădiri se pare că nu vedem niciun „modem/routere Comcast” provenit de la rezidenți conectați din greșeală în sistemul nostru.

Vreo idee?

A trecut ceva timp de când am lucrat în Telecomunicații, dar voi avea în urmă.

Se pare că aveți o buclă de rețea sau, după cum spuneți, rezidenții au creat o scurgere. Când cablul OLT la router este deconectat, rețeaua găsește o rută către internet înainte de a începe backup-ul. În acest caz, găsește o rută prin conexiunea rezidenților la routerul lor comcast. Odată ce o rută este stabilită astfel, se poate ca, deși o rută mai adecvată devine disponibilă atunci când apare backup-ul, aceasta nu resetează tabelele routerului (poate pentru că nu vede că este nevoie).

Acest lucru ar putea fi din cauza priorităților de rutare.

Problema eșecului DNS se datorează probabil că acest port nu este disponibil prin această pseudo rută sau are o prioritate atât de scăzută încât pachetele pur și simplu se pierd. Dacă căutarea inițială a DNS (și aici cunoștințele mele devin un pic cam slabe) se face prin UDP, s-ar putea ca numai atunci când revine la TCOP să ajungă. Dar chiar nu sunt sigur aici.

Am avut aceeași problemă cu zeci de ani în urmă, când am constatat că pe o legătură eșuată, cineva instalase o legătură de linie telefonică care se conectează automat la lumea exterioară. Singura problemă a fost că, atunci când legătura principală s-a întors, nu a întrerupt legătura dialup, iar întreaga companie a fost apoi direcționată prin acest modem de 9.6K. A fost nevoie de ani de zile pentru a găsi, pentru că nimeni nu ar recunoaște ceea ce a făcut. Se pare că ai ceva asemănător.