Puncte:0

NFSv4 și kerberos: acces refuzat 50% din timp

drapel bd

Încercăm să instalăm partajări NFSv4 pe clienții RHEL 8, cu kerberos.Avem o configurație foarte similară în alt mediu și a funcționat bine. Dar în această configurație, se întâmplă să obținem acces interzis de aproximativ 50% din cazuri încercăm să creăm o cotă:

# incercare eșuată

bash-4.4$ sudo mount -t nfs -o sec=krb5 server.com:/homes/francis test -vvvv
mount.nfs: expirare stabilită pentru sâmbătă, 2 apr. 16:28:32 2022
mount.nfs: încercarea de opțiuni bazate pe text 'sec=krb5,vers=4.2,addr=192.168.1.89,clientaddr=192.168.2.29'
mount.nfs: mount(2): Protocolul nu este acceptat
mount.nfs: încercarea de opțiuni bazate pe text 'sec=krb5,vers=4,minorversion=1,addr=192.168.1.89,clientaddr=192.168.2.29'
mount.nfs: mount(2): Protocolul nu este acceptat
mount.nfs: încercarea de opțiuni bazate pe text 'sec=krb5,vers=4,addr=192.168.1.89,clientaddr=192.168.2.29'
mount.nfs: mount(2): Permisiune refuzată
mount.nfs: încercarea de opțiuni bazate pe text 'sec=krb5,vers=4,addr=192.168.1.88,clientaddr=192.168.2.29'
mount.nfs: mount(2): Permisiune refuzată
mount.nfs: încercarea de opțiuni bazate pe text „sec=krb5,addr=192.168.1.89”
mount.nfs: prog 100003, încercând vers=3, prot=6
mount.nfs: se încearcă 192.168.1.89 prog 100003 vers 3 prot portul TCP 2049
mount.nfs: prog 100005, încercând vers=3, prot=17
mount.nfs: se încearcă 192.168.1.89 prog 100005 vers 3 prot portul UDP 32767
mount.nfs: mount(2): Permisiune refuzată
mount.nfs: încercarea de opțiuni bazate pe text „sec=krb5,addr=192.168.1.88”
mount.nfs: prog 100003, încercând vers=3, prot=6
mount.nfs: se încearcă 192.168.1.88 prog 100003 vers 3 prot portul TCP 2049
mount.nfs: prog 100005, încercând vers=3, prot=17
mount.nfs: se încearcă 192.168.1.88 prog 100005 vers 3 prot portul UDP 32767
mount.nfs: mount(2): Permisiune refuzată
mount.nfs: acces refuzat de server în timpul instalării hypatia.uio.no:/uioit-usit-drift-homes/francis

# încercare de lucru două secunde mai târziu
bash-4.4$ sudo mount -t nfs -o sec=krb5 server.com:/homes/francis test -vvvv
mount.nfs: expirare stabilită pentru sâmbătă, 2 apr. 16:30:09 2022
mount.nfs: încercarea de opțiuni bazate pe text 'sec=krb5,vers=4.2,addr=192.168.1.88,clientaddr=192.168.2.29'
mount.nfs: mount(2): Protocolul nu este acceptat
mount.nfs: încercarea de opțiuni bazate pe text 'sec=krb5,vers=4,minorversion=1,addr=192.168.1.88,clientaddr=192.168.2.29'
mount.nfs: mount(2): Protocolul nu este acceptat
mount.nfs: încercarea de opțiuni bazate pe text 'sec=krb5,vers=4,addr=192.168.1.88,clientaddr=192.168.2.29'
mount.nfs: mount(2): Permisiune refuzată
mount.nfs: încercarea de opțiuni bazate pe text 'sec=krb5,vers=4,addr=192.168.1.89,clientaddr=192.168.2.29'

Am verificat jurnalele de pe partea clientului și nu prea multe acolo care să indice cauza eșecului de montare. Funcționează o singură dată și nu va funcționa două secunde mai târziu. Sau vice versa.

M-am gândit la început că ar putea fi o problemă de montare încrucișată, dar am încercat și cu directorul superior al share-ului și a fost aceeași problemă.

Orice indicii despre care poate fi problema?

stark avatar
drapel mu
Clientul și serverul sunt pe subrețele diferite? Ați verificat jurnalele routerului și firewall-ului?
drapel fr
`server.com` dvs. pare să se rezolve la două adrese IP: 192.168.1.88 și 192.168.1.89. Aceste două adrese au mapare DNS inversă corectă, care indică înapoi către „server.com”? Kerberos este destul de pretențios când vine vorba de configurarea corectă a DNS.
drapel bd
Există un punct bun @Tomek. Ambele adrese au câte două înregistrări PTR și asta ar putea fi problema.Deși am o configurație în care serverul nu are un PTR și funcționează destul de bine, dacă am PTR care nu se rezolvă la gazda pe care o folosesc ar putea înrăutăți lucrurile.
drapel bd
@stark da, subrețele diferite, dar din punct de vedere al rețelei, totul este bine.
drapel fr
Dacă nu puteți rezolva problema DNS (ceea ce ar trebui), puteți încerca să setați setarea `rdns` în `krb5.conf` la `false` și să vedeți dacă vă ajută (ar trebui, dar uneori poate fi suprascris la nivel de aplicație, am cred că OpenSSH face asta dacă este configurat pentru a face acest lucru).
drapel bd
@Tomek Am încercat asta cu rulări (Există ceva care trebuie repornit?) și nu a funcționat. Văd dacă pot elimina înregistrările PTR care nu se rezolvă înapoi la numele de gazdă al principalului pentru montarea nfs pentru a vedea dacă asta ajută.
drapel fr
Posibil rpc.gssd... Dar nu sunt sigur.
Puncte:0
drapel bd

Problema, în cazul meu, a fost că erau două PTR configurate pentru server. Chiar și folosind rdns=fals nu a ajutat. La eliminarea PTR-ului care nu s-a rezolvat înapoi la numele de gazdă care se potrivește cu principalul pentru server, lucrurile au funcționat mult mai bine.

Mulțumesc @Tomek pentru pont.

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.