Kerio Linuxis: anda kvnetile MAC, mida server ootab

Kolm asja peavad ühtima, enne kui Kerio tunnel liiklust kannab: aadress kvnet liidesel, väärtus, mille klient logis, ja see, mida serveri poliitika või DHCP ootab. Kui need ei ühti, autentib tunnel endiselt ja tõuseb endiselt üles, ja just see teebki rikke segadust tekitavaks. Liides luuakse ühenduse kohta, seega käsitsi seatud aadress kuulub sellele sessioonile ja mitte millelegi muule. See on probleemi kuju ja lahendus on konks, mitte konfiguratsioonifail. Ülejäänu on see, kust väärtust lugeda ja kus seda rakendada.

Miks aadress aina tagasi pöördub

kvnet on virtuaalne adapter, mille klient loob ühenduse alguses ja eemaldab selle lõpus. Käsitsi tehtud ip link set püsib seega täpselt nii kaua kui sessioon, millele seda rakendati, ja järgmine ühendus algab sellest, mida klient määrab. Masinas, kus klient ei suuda oodatud aadressi rakendada, toob iga uus ühendus sama lahknevuse uuesti sisse ja liisingu- või juurdepääsureegel lükkab seadme taas tagasi.

See muster on iseenesest diagnostiline. Tunnel, mis töötab ühe sessiooni ja ebaõnnestub järgmises, ei ole mandaadi probleem, sest mandaadid ei muutu ühenduste vahel.

Lugege väärtust kliendist, mitte liideselt

Linuxi klient kirjutab läbirääkimise üksikasjad oma silumislogisse ja aadress, mida ta kavatseb kasutada, ilmub sinna ühendusjärjestuse viimase aadressikujulise tokenina. Võrrelge seda sellega, mida kernel tegelikult hoiab, mis on ühe readlinki kaugusel: cat /sys/class/net/kvnet/address.

Kui need kaks erinevad, teadis klient õiget väärtust ja ei suutnud seda rakendada, ning konks, mis rakendab seda pärast liidese olemasolu, sulgeb selle lõhe. Kui logis pole üldse aadressi, on probleem varasem ja kuulub kliendi versiooni või serveri profiili, mitte skripti juurde.

Rakendage seda pärast liidese olemasolu

NetworkManageri kasutajad saavad panna skripti selle dispetšeri kataloogi ja tegutseda ainult siis, kui VPN-i liides tõuseb. systemd-ga hallatav klient nõuab rohkem hoolt: teenuse käivitamisel jooksev drop-in aktiveerub tavaliselt enne, kui adapter olemas on, seega peab konks liidest ootama, selle asemel et seda eeldada. Määrake aadress siis, ja kui kernel keeldub, kui link on üleval, võtke see alla, määrake aadress ja tõstke uuesti üles. Lugege eraldatud token MAC-mustri kaudu tagasi enne, kui annate selle ip link-ile, et ootamatu logirida ei saaks argumendiks.

Kõik, mis jookseb rootina kliendi logist, väärib kitsast omandit: rootile kuuluv fail, millele teised ei saa kirjutada, ja mingit shelli interpoleerimist üle valideeritud aadressi. Hoidke mustrikontroll skripti sees. Ärge laske logi sisul otsustada, milline käsk jookseb.

Kontrollige liisingut, mitte linki

ip -4 -o addr show dev kvnet peaks näitama aadressi oodatud vahemikus, ip neigh show dev kvnet peaks näitama lüüsi, ja üks VPN-i taga olev teenus peaks vastama. Seejärel katkestage ja taasühendage korra; kui aadress pöördub tagasi, käivitub konks vale sündmuse peale või ei käivitu üldse.

Liides, mis ilmub õige aadressiga ja ei saa kunagi liisingut, osutab serveripoolele. See on teine kontroll ja tavaliselt teine meeskond. Kinnitage, et konto on lubatud ja poolis on veel aadress, enne kui konksu uuesti muudate.

Vaadake ümbersõit pärast uuendust uuesti üle

Kliendi versioon, mis seab aadressi õigesti, jätab teie konksu rakendama vana väärtust, mis on paranduse tekitatud uus rike. Ärge kunagi kopeerige MAC-i ka teisest masinast ega foorumipostitusest; kasutage väärtust, mille see klient selle konto jaoks logib, ja märkige üles kuupäev, millal te seda kontrollisite.

Hoidke skript lühike, et seda ühe istumisega lugeda. Logisid parsivad ümbersõidud on oma olemuselt ajutised. Ellu jäävad need, mida tulevane lugeja mõistab ilma algse lõimeta.