Kerio på Linux: ge kvnet det MAC som servern förväntar sig

Tre saker måste stämma innan en Kerio-tunnel transporterar trafik: adressen på kvnet-gränssnittet, värdet som klienten loggade och det som serverpolicyn eller DHCP förväntar sig. När de inte stämmer autentiserar tunneln ändå och kommer ändå upp, och det är just det som gör felet förvirrande. Gränssnittet skapas per anslutning, så en adress som satts för hand tillhör den sessionen och ingenting annat. Det är problemets form, och lösningen är en hook i stället för en konfigurationsfil. Resten handlar om var värdet läses och var det tillämpas.

Varför adressen ständigt faller tillbaka

kvnet är en virtuell adapter som klienten skapar när en anslutning startar och tar bort när den avslutas. En manuell ip link set överlever därför exakt så länge som sessionen den tillämpades på, och nästa anslutning börjar med det klienten tilldelar. På en maskin där klienten inte lyckas tillämpa den förväntade adressen återinför varje återanslutning samma avvikelse, och lease- eller åtkomstregeln avvisar enheten igen.

Det mönstret är diagnostiskt i sig. En tunnel som fungerar en session och misslyckas i nästa är inte ett autentiseringsproblem, eftersom autentiseringsuppgifter inte ändras mellan anslutningar.

Läs värdet från klienten, inte från gränssnittet

Linux-klienten skriver förhandlingsdetaljer till sin felsökningslogg, och adressen den avser att använda visas där som den sista adressformade token i anslutningssekvensen. Jämför det med vad kärnan faktiskt håller, vilket är en readlink bort: cat /sys/class/net/kvnet/address.

Om de två skiljer sig kände klienten det rätta värdet och lyckades inte tillämpa det, och en hook som tillämpar det efter att gränssnittet finns stänger luckan. Om loggen inte innehåller någon adress alls är problemet tidigare och hör till klientversionen eller serverprofilen snarare än till ett skript.

Tillämpa det efter att gränssnittet finns

Användare av NetworkManager kan lägga ett skript i dess dispatcher-katalog och agera först när VPN-gränssnittet kommer upp. En systemd-styrd klient kräver mer omsorg: en drop-in som körs vid tjänstestart utlöses vanligtvis innan adaptern finns, så hooken måste vänta på gränssnittet i stället för att förutsätta det. Sätt adressen då, och om kärnan vägrar medan länken är uppe, ta ner den, sätt adressen och ta upp den igen. Läs den extraherade token tillbaka genom ett MAC-mönster innan du ger den till ip link, så att en oväntad logglinje inte kan bli ett argument.

Allt som körs som root utifrån en klients logg förtjänar smalt ägande: en fil som ägs av root, inte skrivbar av andra, och ingen shell-interpolering utöver den validerade adressen. Håll mönsterkontrollen inne i skriptet. Låt inte logginnehållet avgöra vilket kommando som körs.

Verifiera leasen i stället för länken

ip -4 -o addr show dev kvnet bör visa en adress i det förväntade intervallet, ip neigh show dev kvnet bör visa gatewayen, och en tjänst bakom VPN:en bör svara. Koppla sedan från och anslut en gång igen; om adressen faller tillbaka utlöses hooken på fel händelse eller inte alls.

Ett gränssnitt som dyker upp med rätt adress och aldrig får en lease pekar på serversidan. Det är en annan kontroll och vanligtvis ett annat team. Bekräfta att kontot är tillåtet och att poolen fortfarande har en adress innan du redigerar hooken igen.

Tänk om workarounden efter en uppgradering

En klientbygg som sätter adressen korrekt låter din hook tillämpa ett inaktuellt värde, vilket är ett nytt fel som en rättelse infört. Kopiera heller aldrig ett MAC från en annan maskin eller ett foruminlägg; använd värdet som den här klienten loggar för detta konto, och anteckna datumet du verifierade det.

Håll skriptet kort nog att läsas i en enda sittning. Workarounds som parsar loggar är tillfälliga till sin natur. De som överlever är de som en framtida läsare förstår utan den ursprungliga tråden.