Adresa IP internă a routerului meu s-a schimbat și, de atunci, TrueNAS s-a comportat prost. Niciuna dintre închisori nu mai poate rezolva un nume de gazdă. În depanarea, am descoperit că clientul nu poate trimite ping la nicio adresă IP externă fără ca răspunsul să fie de la gazdă.
Pentru informatii:
- În acest exemplu, IP-ul închisorii client este 10.153.2.250
- IP-ul gazdei (FreeNAS) este 10.153.2.9
- Noul gateway este 10.0.55.1 (vechiul era 10.55.0.1), iar acesta a fost actualizat atât în configurația rețelei gazdei, cât și a închisorilor.
- Când IP-ul gateway-ului s-a schimbat, FreeNAS a intrat într-o buclă de pornire la următoarea pornire... aparent la o eroare a rezoluției DNS. După cum îmi amintesc (era 3 dimineața și mintea mea era încețoșată), actualizarea serverului de nume și a rutei a remediat în sfârșit.
- O partajare SMB pe gazdă a încetat să funcționeze în același timp (și încă nu a revenit)
Nu se pot trimite ping la nume de domenii:
dus-întors min/avg/max/stddev = 15,553/15,790/16,027/0,237 ms
root@jail:~ # ping google.com
ping: nu se poate rezolva google.com: eșecul de căutare a numelui gazdei
Dacă manual îi spun clientului de închisoare să caute un domeniu, primesc înapoi o adresă IP:
root@jail:~ # gazdă google.com
google.com are adresa 172.217.15.110
google.com are adresa IPv6 2607:f8b0:4009:801::200e
E-mailul google.com este gestionat de 10 aspmx.l.google.com.
E-mailul google.com este gestionat de 30 alt2.aspmx.l.google.com.
E-mailul google.com este gestionat de 50 alt4.aspmx.l.google.com.
E-mailul google.com este gestionat de 8 smtp.google.com.
E-mailul google.com este gestionat de 40 alt3.aspmx.l.google.com.
E-mailul google.com este gestionat de 20 alt1.aspmx.l.google.com.
CU toate acestea, pentru orice adresă IP pe care o fac ping din interiorul clientului de închisoare, răspunsul este de la IP-ul gazdei închisorii (FreeNAS). Punerea ping la aceleași IP-uri de la gazdă obține un răspuns normal.
root@jail:~ # ping 172.217.15.110
PING 172.217.15.110 (172.217.15.110): 56 de octeți de date
64 de octeți din 10.153.2.9: icmp_seq=0 ttl=116 timp=30,454 ms
64 de octeți din 10.153.2.9: icmp_seq=1 ttl=116 timp=30,235 ms
64 de octeți din 10.153.2.9: icmp_seq=2 ttl=116 timp=30,534 ms
^C
--- 172.217.15.110 statistici ping ---
3 pachete transmise, 3 pachete primite, 0,0% pierdere de pachete
dus-întors min/avg/max/stddev = 30,235/30,408/30,534/0,126 ms
Un alt exemplu (notați IP-ul gazdei, 10.153.2.9, în răspuns):
root@jail:~ # ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 de octeți de date
64 de octeți din 10.153.2.9: icmp_seq=0 ttl=57 time=16.027 ms
64 de octeți din 10.153.2.9: icmp_seq=1 ttl=57 timp=15,553 ms
^C
--- 1.1.1.1 statistici ping ---
2 pachete transmise, 2 pachete primite, 0,0% pierdere de pachete
Dar, dacă dau ping la un alt IP intern (altul decât cel al routerului), primesc răspunsul așteptat:
root@jail:~ # ping 10.153.2.205
PING 10.153.2.205 (10.153.2.205): 56 de octeți de date
64 de octeți din 10.153.2.205: icmp_seq=0 ttl=64 time=0,295 ms
64 de octeți din 10.153.2.205: icmp_seq=1 ttl=64 time=0,237 ms
64 de octeți din 10.153.2.205: icmp_seq=2 ttl=64 time=0,193 ms
^C
--- 10.153.2.205 statistici ping ---
3 pachete transmise, 3 pachete primite, 0,0% pierdere de pachete
dus-întors min/avg/max/stddev = 0,193/0,242/0,295/0,042 ms
root@jail:~
Iată rezultatul netstat -rn din interiorul gazdei. Nu sunt prea familiarizat cu această ieșire, dar nimic nu mi se pare la fel de rău (și seamănă foarte mult cu versiunea gazdei):
root@jail:~ # netstat -rn
Tabelele de rutare
Internet:
Destination Gateway Flags Netif Expire
implicit 10.0.55.1 UGS epair0b
10.0.0.0/8 link#3 U epair0b
10.153.2.250 link#3 UHS lo0
127.0.0.1 link#1 UH lo0
Internet6:
Destination Gateway Flags NetifExpire
::/96 ::1 UGRS lo0
::1 link#1 UH lo0
::ffff:0.0.0.0/96 ::1 UGRS lo0
fe80::/10 ::1 UGRS lo0
fe80::%lo0/64 link#1 U lo0
fe80::1%lo0 link#1 UHS lo0
ff02::/16 ::1 UGRS lo0
Iată conținutul clientului rezoluție.conf (identic cu cel al gazdei rezoluție.confși se potrivește în mod previzibil cu setările din configurația rețelei FreeNAS):
root@jail:~ # cat /etc/resolv.conf
# Generat de resolvconf
caută local
server de nume 1.1.1.1
serverul de nume 1.0.0.1
serverul de nume 10.0.55.1
root@jail:~
Am verificat arp cache-ul și adresele MAC sunt corecte.
Deci....de ce închisoarea ar primi IP-ul gazdei înapoi într-un răspuns ping?
