Kial la vpnc-itinera-puriga averto aperas en ujo
La purigo de la itin-kaŝmemoro estas restaĵo de kerno, kiu jam ne tenas tiun kaŝmemoron; la nurlega eraro venas de la muntado de la ujo, ne de la tunelo.
Freŝaj ujaj protokoloj ofte finiĝas per plendo Read-only file system pri /proc/sys/net/ipv4/route/flush, kaj tiu linio kulpiĝas pro tunelo, kiu povas esti tute sana. La skribo malantaŭ ĝi celas kernan eron, kiu jam faras nenion utilan, ĉar la IPv4-itin-kaŝmemoro malaperis. En ujo /proc/sys muntiĝas nurlege, do la alidirektado rifuziĝas antaŭ ol ajna valoro alvenas kaj la ŝelo presas tiun rifuzon. Funkcianta tunelo povas presi ĉi tiun averton tiel longe, kiel la malnova linio restas en la skripto, kaj --privileged neniam igas la skribon senchava.
Kion la skripto provis purigi
Pli malnovaj konektaj skriptoj finiĝis per kaŝmemora purigo: skribi valoron en kernan regadan dosieron kaj peti al la IPv4-stako forĵeti sian enkursigan kaŝmemoron, por ke nova tunela itinero estiĝu elektita sen atendi, ke eksdataj eroj eksvalidiĝu. La dosiero estis adresita sub /proc/sys/net/ipv4/, kio igis la operacion ŝela alidirektado anstataŭ enkursiga komando. Kerno 3.6 forigis tiun kaŝmemoron, kaj kun ĝi la kialon de la purigo. Nenio en la nuna datenvojo dependas de tiu skribo.
La ero mem postvivis kiel malnova skriba nur-dosiero, do skripto, kiu ankoraŭ skribas en ĝin, atingas realan vojon kaj realan permesan kontrolon. Sur gastiganto la skribo redonas sukceson kaj ŝanĝas nenion. En ujo la sama alidirektado trafas nurlegan /proc/sys kaj malsukcesas per EROFS, kiun la ŝelo presas kiel la nurlegan dosiersisteman mesaĝon. Sur kernoj, kie la vojo vere forestas, la vortumo iĝas No such file or directory, kaj la konkludo ne ŝanĝiĝas.
La du eraroj diras malsamajn aferojn, kaj la diferencon indas teni klare. Read-only file system signifas, ke la kerno atingis eron kaj rifuzis la skribon; No such file or directory signifas, ke la ero malaperis. Neniu mesaĝo raportas pri la tunela aparato, la itineroj aŭ la nomrezolucio, do neniu povas pravigigi pli da privilegioj.
La ordo estas tio, kio igas la mesaĝon ŝajni kaŭza. Konekta skripto instalas itinerojn, ŝanĝas interfacan staton kaj reverkas nomrezolucion antaŭ ol atingi la purigon ĉe la fino, do la laste presita linio estas la linio, kiun homoj citas, eĉ kiam ĉiu grava paŝo redonis sukceson. Tunelo, kiu establiĝas kaj portas trafikon dum ĝi presas ĉi tiun averton, kongruas precize kun la mekanismo supre.
Kontrolu la muntadon kaj la itineron antaŭ ol aldoni privilegion
Tri legadoj apartigas kosmetikan averton de reala fiasko: ĉu la instalita skripto ankoraŭ portas la linion, kiel /proc/sys muntiĝas, kaj kien la trafiko de la aplikaĵo vere iras. Rulu ilin en la sama uja nomspaco aŭ sur la gastiganto, kie la averto aperis, ĉar kontrolo sur nerilata maŝino respondas al alia demando.
grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10La respondo de grep estas pli malforta, ol ĝi aspektas, ĉar trafo pruvas, ke la linio ekzistas, ne ke ĝi funkcias sen gardo; prizorgata skripto povas porti la skribon ene de gardo, kiu preterpasas ĝin. findmnt -no OPTIONS /proc/sys decidas la muntadon rekte, kaj ro en tiu eligo signifas, ke ĉiu skribo sub tiu punkto rifuziĝas, kion ajn faras la skripto. La itinera serĉo poste montras, ĉu la celo bezonata de la aplikaĵo solviĝas tra la tunela interfaco aŭ tra la defaŭlta enirejo de la ujo. Serĉo, kiu elektas la defaŭltan enirejon, signifas, ke la tunelo leviĝis kaj nenio enkursiĝas en ĝin, kio estas enkursiga problemo kaj ne privilegia.
De kie la riparo efektive venas
La prizorgata riparo loĝas en la skripto, ne en la ujaj flagoj. La upstream vpnc-script ŝanĝis, kiel ĝi traktas ĉi tiun operacion, do komparu la kopion ene de la bildo kun la nuna upstream kaj ĝisdatigu per la pakaĵo aŭ bildkonstruo, kiu provizas ĝin. Mane redaktita dosiero ene de kuranta ujo ne estas revizebla kaj ne postvivos la sekvan konstruon.
--privileged estas dokumentita kiel donanta ĉiujn kapablecojn plus vastan aparatan aliron, granda koncedo por mesaĝo, kiu ŝanĝas nenion, do nomu la mankan kapablecon anstataŭe, se unu vere forestas. Post la ĝisdatigo, ripetu la itineran serĉon kaj lasu aplikaĵon uzi la tunelon, ĉar trankvila protokolo kaj funkcianta konekto estas apartaj rezultoj.