Kerio på Linux: giv kvnet den MAC, serveren forventer

Tre ting skal stemme overens, før en Kerio-tunnel fører trafik: adressen på interfacet kvnet, den værdi klienten loggede, og det serverpolitikken eller DHCP forventer. Når de er uenige, autentificerer tunnelen stadig og kommer stadig op, og det er netop det, der gør fejlen forvirrende. Interfacet oprettes pr. forbindelse, så en adresse, der sættes manuelt, tilhører den session og intet andet. Det er problemets form, og løsningen er en hook frem for en konfigurationsfil. Resten handler om, hvor værdien læses, og hvor den anvendes.

Hvorfor adressen bliver ved med at vende tilbage

kvnet er en virtuel adapter, som klienten opretter, når en forbindelse starter, og fjerner, når den slutter. En manuel ip link set overlever derfor præcis så længe som den session, den blev anvendt på, og den næste forbindelse starter med det, klienten tildeler. På en maskine, hvor klienten ikke får anvendt den forventede adresse, genindfører hver genopkobling den samme uoverensstemmelse, og lease- eller adgangsreglen afviser enheden igen.

Det mønster er diagnostisk i sig selv. En tunnel, der virker i én session og fejler i den næste, er ikke et legitimationsproblem, for legitimationsoplysninger ændrer sig ikke mellem forbindelser.

Læs værdien fra klienten, ikke fra interfacet

Linux-klienten skriver forhandlingsdetaljer til sin fejlretningslog, og den adresse, den agter at bruge, optræder der som det sidste adresseformede token i forbindelsessekvensen. Sammenlign det med, hvad kernen faktisk har, hvilket er ét readlink væk: cat /sys/class/net/kvnet/address.

Hvis de to afviger, kendte klienten den rigtige værdi og fik den ikke anvendt, og en hook, der anvender den, efter interfacet findes, lukker hullet. Hvis loggen slet ikke indeholder en adresse, er problemet tidligere og hører til klientversionen eller serverprofilen snarere end til et script.

Anvend den, efter interfacet findes

Brugere af NetworkManager kan lægge et script i dens dispatcher-mappe og handle, kun når VPN-interfacet kommer op. En systemd-styret klient kræver mere omhu: et drop-in, der kører ved tjenestestart, udløses normalt, før adapteren findes, så hooken skal vente på interfacet i stedet for at forudsætte det. Sæt adressen da, og hvis kernen nægter, mens linket er oppe, så tag det ned, sæt adressen, og bring det op igen. Læs det udtrukne token tilbage gennem et MAC-mønster, før det gives til ip link, så en uventet loglinje ikke kan blive et argument.

Alt, der kører som root ud fra en klients log, fortjener snævert ejerskab: en fil ejet af root, ikke skrivbar for andre, og ingen shell-interpolering ud over den validerede adresse. Hold mønsterkontrollen inde i scriptet. Lad ikke logindhold afgøre, hvilken kommando der kører.

Verificér leasen frem for linket

ip -4 -o addr show dev kvnet bør vise en adresse i det forventede område, ip neigh show dev kvnet bør vise gatewayen, og én tjeneste bag VPN’en bør svare. Afbryd derefter og genopkobl én gang; hvis adressen vender tilbage, udløses hooken på den forkerte hændelse eller slet ikke.

Et interface, der dukker op med den rigtige adresse og aldrig får en lease, peger på serversiden. Det er en anden kontrol og normalt et andet team. Bekræft, at kontoen er tilladt, og at poolen stadig har en adresse, før hooken redigeres igen.

Genovervej workarounden efter en opgradering

Et klientbuild, der sætter adressen korrekt, efterlader din hook til at anvende en forældet værdi, hvilket er en ny fejl indført af en rettelse. Kopiér heller aldrig en MAC fra en anden maskine eller et forumindlæg; brug den værdi, denne klient logger for denne konto, og notér den dato, du verificerede den.

Hold scriptet kort nok til at læse i én omgang. Workarounds, der parser logs, er af natur midlertidige. Dem, der overlever, er dem, en fremtidig læser kan forstå uden den oprindelige tråd.