Kerio på Linux: gi kvnet MAC-en serveren forventer

Tre ting må stemme før en Kerio-tunnel fører trafikk: adressen på kvnet-grensesnittet, verdien klienten loggførte, og det serverpolicyen eller DHCP forventer. Når de ikke stemmer, autentiserer tunnelen likevel og kommer likevel opp, og nettopp det gjør feilen forvirrende. Grensesnittet opprettes per tilkobling, så en adresse satt for hånd tilhører den økten og ingenting annet. Det er problemets form, og løsningen er en hook fremfor en konfigurasjonsfil. Resten handler om hvor verdien leses og hvor den brukes.

Hvorfor adressen stadig faller tilbake

kvnet er en virtuell adapter som klienten oppretter når en tilkobling starter og fjerner når den avsluttes. En manuell ip link set overlever derfor nøyaktig så lenge som økten den ble brukt på, og neste tilkobling starter med det klienten tildeler. På en maskin der klienten ikke får brukt den forventede adressen, gjeninnfører hver gjenoppkobling samme avvik, og lease- eller tilgangsregelen avviser enheten igjen.

Det mønsteret er diagnostisk i seg selv. En tunnel som virker én økt og feiler i den neste, er ikke et legitimasjonsproblem, for legitimasjon endres ikke mellom tilkoblinger.

Les verdien fra klienten, ikke fra grensesnittet

Linux-klienten skriver forhandlingsdetaljer til feilsøkingsloggen sin, og adressen den har tenkt å bruke, vises der som det siste adresseformede tokenet i tilkoblingssekvensen. Sammenlign det med det kjernen faktisk holder, som er én readlink unna: cat /sys/class/net/kvnet/address.

Hvis de to er forskjellige, kjente klienten riktig verdi og fikk den ikke brukt, og en hook som bruker den etter at grensesnittet finnes, lukker gapet. Hvis loggen ikke inneholder noen adresse i det hele tatt, er problemet tidligere og hører til klientversjonen eller serverprofilen snarere enn til et skript.

Bruk den etter at grensesnittet finnes

Brukere av NetworkManager kan legge et skript i dispatcher-katalogen og handle bare når VPN-grensesnittet kommer opp. En systemd-styrt klient krever mer omhu: en drop-in som kjører ved tjenestestart, utløses vanligvis før adapteren finnes, så hooken må vente på grensesnittet i stedet for å forutsette det. Sett adressen da, og hvis kjernen nekter mens linken er oppe, ta den ned, sett adressen og ta den opp igjen. Les det uttrukne tokenet tilbake gjennom et MAC-mønster før du gir det til ip link, slik at en uventet logglinje ikke kan bli et argument.

Alt som kjører som root ut fra loggen til en klient, fortjener smal eierskap: en fil eid av root, ikke skrivbar av andre, og ingen shell-interpolering utover den validerte adressen. Hold mønsterkontrollen inne i skriptet. Ikke la logginnhold avgjøre hvilken kommando som kjøres.

Verifiser leasen fremfor linken

ip -4 -o addr show dev kvnet bør vise en adresse i det forventede området, ip neigh show dev kvnet bør vise gatewayen, og én tjeneste bak VPN-en bør svare. Koble deretter fra og tilkoble én gang; hvis adressen faller tilbake, utløses hooken på feil hendelse eller ikke i det hele tatt.

Et grensesnitt som dukker opp med riktig adresse og aldri får en lease, peker på serversiden. Det er en annen kontroll og vanligvis et annet team. Bekreft at kontoen er tillatt og at poolen fortsatt har en adresse, før du redigerer hooken igjen.

Vurder workarounden på nytt etter en oppgradering

En klientbygg som setter adressen riktig, lar hooken din bruke en utdatert verdi, som er en ny feil innført av en rettelse. Kopier heller aldri en MAC fra en annen maskin eller et foruminnlegg; bruk verdien denne klienten loggfører for denne kontoen, og noter datoen du verifiserte den.

Hold skriptet kort nok til å leses i én økt. Workarounds som parser logger, er av natur midlertidige. De som overlever, er de en fremtidig leser forstår uten den opprinnelige tråden.