NFS clientaddr super VPN: decidu laŭ la malĉefa versio, ne laŭ kutimo
clientaddr anoncas revokadreson nur por NFSv4.0. Legu la interkonsentitan malĉefan version, kontrolu la revenan vojon kaj apartigu ĝin de muntaj malsukcesoj.
clientaddr estas unu el tiuj muntaj opcioj, kiujn oni kopias en komandan linion longe post kiam la kialo por ĝi malaperis. Ĝi diras al NFSv4.0-servilo, kien revoki la klienton. Ĝi ne elektas la servilon, ne ligas ĉiun peton al fonta adreso kaj ne pelas trafikon en tunelon. Ĉe tekkomputilo kun pluraj adresoj, por decidi ĉu ĝi entute aplikiĝas, necesas tri demandoj.
Tri kondiĉoj decidas ĉu la opcio gravas
La unua estas la interkonsentita malĉefa versio, ĉar 4.1 kaj 4.2 traktas revokojn malsame. La dua estas ĉu la servilo povas atingi la adreson, kiun vi anoncus; enkursigita tunelo kutime permesas tion, tradukita vojo kutime ne. La tria estas ĉu la malsukceso, kiun vi postkuras, entute estas revoka malsukceso.
| Condition | If yes | If no |
|---|---|---|
| Version is 4.0 | The option can matter | Skip it; inspect the session instead |
| Server can reach the address | Advertise it | Fix reachability first |
| Failure is a callback | Diagnose callback path | Look at mount and export |
Respondi ilin laŭ malĝusta ordo estas kiel homoj aldonas revokadreson al 4.2-munto kaj konkludas, ke la opcio estas rompita.
Unue legu la malĉefan version
nfsstat -mPor ekzistanta munto, ĉi tio presas la muntajn informojn kaj flagojn, inkluzive de la efektiva versio kiel vers=4.0, vers=4.1 aŭ vers=4.2. Noto, kiu diras nur “NFSv4”, preterlasas la solan detalon, kiu decidas ĉu ĉi tiu opcio estas grava. Legu la nombron, ne la vorton.
Se la versia ĉeno venis de servila defaŭlto anstataŭ de via komanda linio, demandu, kiun malĉefan version oni interkonsentis. Servilo povas rifuzi pli altan malĉefan version kaj retroiri, kaj ĝuste tiu retroiro estas la kazo, kiam revoko subite gravas. La munta linio, kiun vi skribis, eble ne priskribas la munto, kiun vi havas.
Por 4.0, anoncu adreson, kiun la servilo povas atingi
NFSv4.0-servilo eble bezonas apartan konekton reen al la kliento, ekzemple kiam ĝi revokas delegacion. Kun pluraj interfacoj aŭ nekutima enkursiga tabelo, la aŭtomata malkovro de revokadreso povas elekti unu, kiun la servilo ne povas uzi.
mount -t nfs -o vers=4.0,clientaddr=10.8.0.6 10.8.0.1:/export /mnt/shareLa adreso antaŭ la dupunkto estas la servilo kaj restas la celo. La revokadreso apartenas al la kliento, kaj ĝi devas esti atingebla de la servila flanko de la tunelo. Bukla adreso direktas la servilon reen al si mem. Privata klienta adreso sen reena vojo estas same neuzebla, kvankam ĝi aspektas ĝusta ĉe la kliento.
Uzu ĉi tion kiel ilustraĵon, ne kiel kialon malaltigi funkciantan munto. Anstataŭigu la adresojn kaj la eksportan vojon, kaj konservu la aŭtentikigon kaj la aliajn opciojn, kiujn la servilo postulas. Forlasi ilin por ke unu ekzemplo taŭgu estas alia ŝanĝo kun alia rezulto, kaj ĉe servilo, kiu devigas sekurecan tipon, ĝi malsukcesas antaŭ ol iu revoko proviĝas.
4.1 kaj 4.2 ne uzas la opcion
Linux NFSv4.1 kaj 4.2 portas revokojn super konektoj, kiujn la kliento starigis, kaj 4.1 nomas tiun instalaĵon backchannel. Ili ne dependas de tio, ke la servilo malfermu novan konekton al anoncita adreso, do clientaddr ne riparas revokan vojon de 4.1 aŭ 4.2.
Tio ne signifas, ke 4.1 kaj 4.2 havas neniujn revokajn problemojn. Ĝi signifas, ke la diagnozo estas alia: ekzamenu la starigitan sesion kaj ĝian backchannel-staton anstataŭ serĉi envenan revokporton, kiu neniam devis ekzisti. Mankanta envena regulo estas la atendata stato, ne fuŝaĵo korektenda.
Apartigu muntan malsukceson de revoka malsukceso
Unue starigu, ĉu la kliento atingas la NFS-servon kaj ĉu la servilo akceptas la eksporton kaj la aŭtentikigan peton. Tempolimo antaŭ tiu interŝanĝo diras nenion pri revokadreso. Ŝanĝi unu dum la munto ankoraŭ malsukcesas ne proksimigas la enketon, kaj ĝi kaŝas la originan eraron malantaŭ nova munta opcio.
Nur kiam la pruvoj montras malsukcesan 4.0-revokon, la anoncita adreso gravas, kune kun la reena vojo de la servilo, la aŭskultanto ĉe la klienta flanko kaj ajna filtrado inter ili. Ŝanĝi la nombron en la munta opcio ne povas krei tiujn vojojn; ĝi povas nur montri al unu, kiu jam ekzistas. Notu, kiun el tiuj kvar vi kontrolis, ĉar la sekva raporto alvenos sen iu ajn el ili.
NFS-radiko ĉe frua lanĉo estas aparta medio kun propraj antaŭkondiĉoj: la initramfs bezonas la ilojn kaj la reton antaŭ ol la munto povas okazi. Munto, kiu funkcias post saluto, pruvas nenion pri tiu sinsekvo, kaj la malsukceso ĉe lanĉo malofte mencias la initramfs aŭ la reton.