Kerio op Linux: kvnet de MAC jaan dy't de tsjinner ferwachtet

Trije dingen moatte oerienkomme foardat in Kerio-tunnel ferkear draacht: it adres op 'e kvnet-ynterface, de wearde dy't de klient logde, en wat it tsjinnerbelied of DHCP ferwachtet. As se net oerienkomme, autentisearret de tunnel noch altyd en komt noch altyd omheech, en krekt dat makket de flater betiizjend. De ynterface wurdt per ferbining oanmakke, dus in adres dat mei de hân set is, heart by dy sesje en by neat oars. Dat is de foarm fan it probleem, en de oplossing is in heakje yn stee fan in konfiguraasjebestân. De rest is wêr't de wearde lêzen en wêr't dy tapast wurde moat.

Wêrom't it adres hieltyd weromkomt

kvnet is in firtuele adapter dy't de klient oanmakket as in ferbining begjint en fuorthellet as dy einiget. In hânmjittige ip link set oerlibbet dêrom krekt sa lang as de sesje dêr't er op tapast waard, en de folgjende ferbining begjint mei wat de klient tawiist. Op in masine dêr't de klient it ferwachte adres net tapasse kin, bringt elke opnij ferbining deselde misferhâlding wer yn, en de lien- of tagongsregel wiist it apparaat wer ôf.

Dat patroan is op himsels diagnostysk. In tunnel dy't ien sesje wurket en de folgjende mislearret, is gjin probleem fan oanmeldgegevens, want dy feroarje net tusken ferbiningen.

Lês de wearde by de klient, net by de ynterface

De Linux-klient skriuwt ûnderhannelingsdetails nei syn debuglog, en it adres dat er fan doel is te brûken ferskynt dêr as it lêste adresfoarmige token fan 'e ferbiningssekwinsje. Ferlykje dat mei wat de kearn wier hat, en dat is ien readlink fuort: cat /sys/class/net/kvnet/address.

As de twa ferskille, wist de klient de juste wearde en koe dy net tapasse, en in heakje dat it tapast neidat de ynterface bestiet, slút dy kleau. As de log hielendal gjin adres befettet, is it probleem earder en heart it by de klientferzje of it tsjinnerprofyl yn stee fan by in skript.

Pas it ta neidat de ynterface bestiet

Brûkers fan NetworkManager kinne in skript yn syn dispatcher-map lizze en allinnich hannelje as de VPN-ynterface omheech komt. In klient ûnder behear fan systemd freget mear soarch: in drop-in dy't by tsjinststart rint, aktivearret meastentiids foardat de adapter bestiet, dus it heakje moat op 'e ynterface wachtsje yn stee fan dy oan te nimmen. Set it adres dan, en as de kearn wegert wylst de link omheech is, helje dy del, set it adres en bring dy wer omheech. Lês it ekstrahearre token werom fia in MAC-patroan foardat jo it oan ip link jouwe, sadat in ûnferwachte logrigel gjin argumint wurde kin.

Alles wat as root rint út 'e log fan in klient fertsjinnet in smelle eigendom: in bestân dat fan root is, net skriuwber foar oaren, en gjin shell-ynterpolaasje foarby it falidearre adres. Hâld de patroankontrôle yn it skript. Lit de logynhâld net beslisse hokker opdracht rint.

Kontrolearje de lien en net de link

ip -4 -o addr show dev kvnet soe in adres yn it ferwachte berik sjen litte, ip neigh show dev kvnet soe de gateway sjen litte, en ien tsjinst efter de VPN soe antwurdzje moatte. Brûk dan de ferbining ôf en ferbinje ien kear opnij; as it adres weromkomt, aktivearret it heakje op 'e ferkearde barren of hielendal net.

In ynterface dy't mei it juste adres ferskynt en nea in lien kriget, wiist op 'e tsjinnerkant. Dat is in oare kontrôle en meastentiids in oar team. Befêstigje dat it akkount tastien is en dat de pool noch in adres hat foardat jo it heakje wer bewurkje.

Besjoch de omsingeling opnij nei in upgrade

In klientbou dy't it adres korrekt set, lit jo heakje in ferâldere wearde tapasse, wat in nije flater is dy't troch in ferbettering ynbrocht is. Kopiearje ek nea in MAC fan in oare masine of in forumberjocht; brûk de wearde dy't dizze klient foar dit akkount logt, en notearje de datum wêrop jo it ferifiearre hawwe.

Hâld it skript koart genôch om it yn ien sitting te lêzen. Omsingelingen dy't logs parsearje binne fan natuere tydlik. Dejingen dy't oerlibje, binne dy't in takomstige lêzer begrypt sûnder it oarspronklike thread.