Kerio op Linux: kvnet de MAC geven die de server verwacht

Drie dingen moeten overeenkomen voordat een Kerio-tunnel verkeer draagt: het adres op de kvnet-interface, de waarde die de client logde, en wat het serverbeleid of DHCP verwacht. Als ze niet overeenkomen, authenticeert de tunnel nog steeds en komt hij nog steeds omhoog, en dat is precies wat de fout verwarrend maakt. De interface wordt per verbinding aangemaakt, dus een handmatig ingesteld adres hoort bij die sessie en bij niets anders. Dat is de vorm van het probleem, en de oplossing is een hook in plaats van een configuratiebestand. De rest is waar de waarde te lezen en waar die toe te passen.

Waarom het adres steeds terugvalt

kvnet is een virtuele adapter die de client aanmaakt wanneer een verbinding begint en verwijdert wanneer die eindigt. Een handmatige ip link set overleeft dus precies zolang als de sessie waarop hij is toegepast, en de volgende verbinding begint met wat de client toewijst. Op een machine waar de client het verwachte adres niet kan toepassen, herintroduceert elke herverbinding dezelfde mismatch, en de lease- of toegangsregel weigert het apparaat opnieuw.

Dat patroon is op zichzelf diagnostisch. Een tunnel die één sessie werkt en de volgende faalt, is geen inloggegevensprobleem, want inloggegevens veranderen niet tussen verbindingen.

Lees de waarde bij de client, niet bij de interface

De Linux-client schrijft onderhandelingsdetails naar zijn foutopsporingslog, en het adres dat hij wil gebruiken verschijnt daar als het laatste adresvormige token in de verbindingsreeks. Vergelijk dat met wat de kernel werkelijk vasthoudt, en dat is één readlink verderop: cat /sys/class/net/kvnet/address.

Als de twee verschillen, kende de client de juiste waarde en slaagde hij er niet in die toe te passen, en een hook die hem toepast nadat de interface bestaat, dicht die kloof. Als het log helemaal geen adres bevat, ligt het probleem eerder en hoort het bij de clientversie of het serverprofiel in plaats van bij een script.

Pas hem toe nadat de interface bestaat

NetworkManager-gebruikers kunnen een script in de dispatcher-map plaatsen en alleen handelen wanneer de VPN-interface omhoogkomt. Een door systemd beheerde client vraagt meer zorg: een drop-in die bij de servicestart draait, wordt meestal geactiveerd voordat de adapter bestaat, dus de hook moet op de interface wachten in plaats van hem aan te nemen. Stel dan het adres in, en als de kernel weigert terwijl de link omhoog is, haal hem neer, stel het adres in en breng hem weer omhoog. Lees het geëxtraheerde token terug via een MAC-patroon voordat je het aan ip link geeft, zodat een onverwachte logregel geen argument kan worden.

Alles wat als root draait op basis van het log van een client verdient nauw eigendom: een bestand in eigendom van root, niet schrijfbaar door anderen, en geen shell-interpolatie buiten het gevalideerde adres. Houd de patrooncontrole in het script. Laat de loginhoud niet bepalen welk commando draait.

Controleer de lease in plaats van de link

ip -4 -o addr show dev kvnet zou een adres in het verwachte bereik moeten tonen, ip neigh show dev kvnet zou de gateway moeten tonen, en één dienst achter de VPN zou moeten antwoorden. Verbreek daarna de verbinding en maak één keer opnieuw verbinding; als het adres terugvalt, wordt de hook door de verkeerde gebeurtenis geactiveerd of helemaal niet.

Een interface die met het juiste adres verschijnt en nooit een lease krijgt, wijst op de serverkant. Dat is een andere controle en meestal een ander team. Bevestig dat het account is toegestaan en dat de pool nog een adres heeft voordat je de hook opnieuw bewerkt.

Herzie de omweg na een upgrade

Een clientbuild die het adres correct instelt, laat je hook een verouderde waarde toepassen, wat een nieuwe fout is die door een reparatie is geïntroduceerd. Kopieer ook nooit een MAC van een andere machine of een forumbericht; gebruik de waarde die deze client voor dit account logt, en noteer de datum waarop je die hebt gecontroleerd.

Houd het script kort genoeg om in één zitting te lezen. Omwegen die logs parseren, zijn van nature tijdelijk. Degene die overleven, zijn degene die een toekomstige lezer begrijpt zonder de oorspronkelijke thread.