Kerio sur Linux: doni al kvnet la MAC-on, kiun la servilo atendas

Tri aferoj devas kongrui antaŭ ol Kerio-tunelo portas trafikon: la adreso sur la interfaco kvnet, la valoro, kiun la kliento protokolis, kaj tio, kion atendas la servila politiko aŭ DHCP. Kiam ili malkongruas, la tunelo tamen aŭtentikigas kaj tamen ekfunkcias, kaj ĝuste tio igas la malsukceson konfuza. La interfaco kreiĝas po konekto, do mane agordita adreso apartenas al tiu seanco kaj al nenio alia. Tia estas la formo de la problemo, kaj la solvo estas hoko anstataŭ agorda dosiero. La resto estas, kie legi la valoron kaj kie apliki ĝin.

Kial la adreso daŭre revenas

kvnet estas virtuala adaptilo, kiun la kliento kreas kiam konekto komenciĝas kaj forigas kiam ĝi finiĝas. Mana ip link set do postvivas ĝuste tiom longe kiom la seanco, al kiu ĝi aplikiĝis, kaj la sekva konekto komenciĝas per tio, kion la kliento atribuas. Sur maŝino, kie la kliento malsukcesas apliki la atendantan adreson, ĉiu rekonekto reenkondukas la saman malkongruon, kaj la luo- aŭ alirregularo denove malakceptas la aparaton.

Tiu ŝablono estas diagnoza per si mem. Tunelo, kiu funkcias por unu seanco kaj malsukcesas ĉe la sekva, ne estas akreditila problemo, ĉar akreditiloj ne ŝanĝiĝas inter konektoj.

Legu la valoron el la kliento, ne el la interfaco

La Linux-kliento skribas intertraktadajn detalojn al sia sencimiga protokolo, kaj la adreso, kiun ĝi intencas uzi, aperas tie kiel la lasta adresforma ĵetono de la konekta sinsekvo. Komparu tion kun tio, kion la kerno efektive tenas, kio estas unu readlink for: cat /sys/class/net/kvnet/address.

Se la du malsamas, la kliento sciis la ĝustan valoron kaj malsukcesis apliki ĝin, kaj hoko, kiu aplikas ĝin post kiam la interfaco ekzistas, fermas tiun breĉon. Se la protokolo enhavas neniun adreson, la problemo estas pli frue kaj apartenas al la klienta versio aŭ la servila profilo, ne al skripto.

Apliku ĝin post kiam la interfaco ekzistas

Uzantoj de NetworkManager povas meti skripton en ĝian dissendan dosierujon kaj agi nur kiam la VPN-interfaco ekfunkcias. Kliento administrata de systemd bezonas pli da zorgo: drop-in, kiu ruliĝas ĉe serva starto, kutime ekbrulas antaŭ ol la adaptilo ekzistas, do la hoko devas atendi la interfacon anstataŭ supozi ĝin. Agordu la adreson tiam, kaj se la kerno rifuzas dum la ligilo estas supre, mallevu ĝin, agordu la adreson kaj relevu ĝin. Legu la eltiritan ĵetonon reen tra MAC-ŝablono antaŭ ol pasigi ĝin al ip link, por ke neatendita protokola linio ne povu fariĝi argumento.

Ĉio, kio ruliĝas kiel root el la protokolo de kliento, meritas mallarĝan posedon: dosiero posedata de root, ne skribebla de aliaj, kaj neniu ŝela interpolado preter la validigita adreso. Tenu la ŝablonkontrolon ene de la skripto. Ne lasu la protokolan enhavon decidi, kiu komando ruliĝas.

Kontrolu la luon anstataŭ la ligilon

ip -4 -o addr show dev kvnet devus montri adreson en la atenda gamo, ip neigh show dev kvnet devus montri la enirejon, kaj unu servo malantaŭ la VPN devus respondi. Poste malkonektu kaj rekonektu unufoje; se la adreso revenas, la hoko ekbrulas ĉe la malĝusta evento aŭ tute ne ekbrulas.

Interfaco, kiu aperas kun la ĝusta adreso kaj neniam ricevas luon, montras al la servila flanko. Tio estas alia kontrolo kaj kutime alia teamo. Konfirmu, ke la konto estas permesita kaj ke la baseno ankoraŭ havas adreson, antaŭ ol denove redakti la hokon.

Repripensu la provizoran solvon post ĝisdatigo

Klienta versio, kiu agordas la adreson ĝuste, lasas vian hokon apliki malnovan valoron, kio estas nova difekto enkondukita de riparo. Ankaŭ neniam kopiu MAC el alia maŝino aŭ forumafŝo; uzu la valoron, kiun ĉi tiu kliento protokolas por ĉi tiu konto, kaj notu la daton, kiam vi kontrolis ĝin.

Tenu la skripton sufiĉe mallonga por legi en unu sidado. Provizoraj solvoj, kiuj analizas protokolojn, estas nature portempaj. La solvoj, kiuj postvivas, estas tiuj, kiujn estonta leganto komprenas sen la origina fadeno.