Kerio på Linux: gje kvnet MAC-en serveren ventar

Tre ting må stemme før ein Kerio-tunnel fører trafikk: adressa på kvnet-grensesnittet, verdien klienten loggførte, og det serverpolitikken eller DHCP ventar. Når dei ikkje stemmer, autentiserer tunnelen likevel og kjem likevel opp, og nettopp det gjer feilen forvirrande. Grensesnittet blir oppretta per tilkopling, så ei adresse sett for hand høyrer til den økta og ingenting anna. Det er forma på problemet, og løysinga er ein krok framfor ei konfigurasjonsfil. Resten handlar om kvar verdien blir lesen og kvar han blir brukt.

Kvifor adressa stadig fell tilbake

kvnet er ein virtuell adapter som klienten opprettar når ei tilkopling startar og fjernar når ho sluttar. Ein manuell ip link set overlever derfor nøyaktig så lenge som økta han vart brukt på, og neste tilkopling startar med det klienten tildeler. På ein maskin der klienten ikkje får brukt den venta adressa, gjeninnfører kvar gjenoppkopling same avviket, og lease- eller tilgangsregelen avviser eininga igjen.

Det mønsteret er diagnostisk i seg sjølv. Ein tunnel som verkar éi økt og feilar i den neste, er ikkje eit legitimasjonsproblem, for legitimasjon endrar seg ikkje mellom tilkoplingar.

Les verdien frå klienten, ikkje frå grensesnittet

Linux-klienten skriv forhandlingsdetaljar til feilsøkingsloggen sin, og adressa han har tenkt å bruke, viser seg der som det siste adresseforma tokenet i tilkoplingssekvensen. Samanlikn det med det kjernen faktisk held, som er éin readlink unna: cat /sys/class/net/kvnet/address.

Viss dei to er ulike, kjende klienten rett verdi og fekk han ikkje brukt, og ein krok som brukar han etter at grensesnittet finst, lukkar gapet. Viss loggen ikkje inneheld noka adresse i det heile, er problemet tidlegare og høyrer til klientversjonen eller serverprofilen snarare enn til eit skript.

Bruk han etter at grensesnittet finst

Brukarar av NetworkManager kan leggje eit skript i dispatcher-katalogen og handle berre når VPN-grensesnittet kjem opp. Ein systemd-styrt klient krev meir omhug: ein drop-in som køyrer ved tenestestart, blir vanlegvis utløyst før adapteren finst, så kroken må vente på grensesnittet i staden for å føresette det. Set adressa då, og viss kjernen nektar medan lenkja er oppe, ta ho ned, set adressa og ta ho opp att. Les det uttrekte tokenet tilbake gjennom eit MAC-mønster før du gir det til ip link, slik at ei uventa logglinje ikkje kan bli eit argument.

Alt som køyrer som root ut frå loggen til ein klient, fortener smal eigarskap: ei fil eigd av root, ikkje skrivbar av andre, og inga shell-interpolering utover den validerte adressa. Hald mønsterkontrollen inne i skriptet. Ikkje la logginnhaldet avgjere kva kommando som blir køyrd.

Stadfest leasen framfor lenkja

ip -4 -o addr show dev kvnet bør vise ei adresse i det venta området, ip neigh show dev kvnet bør vise gatewayen, og éin teneste bak VPN-en bør svare. Kople deretter frå og tilkople éin gong; viss adressa fell tilbake, blir kroken utløyst på feil hending eller ikkje i det heile.

Eit grensesnitt som dukkar opp med rett adresse og aldri får ein lease, peikar på serversida. Det er ein annan kontroll og vanlegvis eit anna team. Stadfest at kontoen er tillaten og at puljen framleis har ei adresse, før du redigerer kroken igjen.

Vurder omvegen på nytt etter ei oppgradering

Eit klientbygg som set adressa rett, lèt kroken din bruke ein utdatert verdi, som er ein ny feil innført av ei retting. Kopier heller aldri ein MAC frå ein annan maskin eller eit foruminnlegg; bruk verdien denne klienten loggfører for denne kontoen, og noter datoen du stadfesta han.

Hald skriptet kort nok til å lesast i éi økt. Omvegar som parsar logger, er av natur mellombelse. Dei som overlever, er dei ein framtidig lesar forstår utan den opphavlege tråden.