Drie dinge moet ooreenstem voordat 'n Kerio-tonnel verkeer dra: die adres op die kvnet-koppelvlak, die waarde wat die kliënt gelog het, en wat die bedienerbeleid of DHCP verwag. Wanneer hulle verskil, verifieer die tonnel steeds en kom steeds op, en dit is juis wat die fout verwarrend maak. Die koppelvlak word per verbinding geskep, so 'n adres wat met die hand gestel word, behoort aan daardie sessie en aan niks anders nie. Dit is die vorm van die probleem, en die oplossing is 'n haak eerder as 'n konfigurasielêer. Die res is waar om die waarde te lees en waar om dit toe te pas.

Waarom die adres aanhou terugval

kvnet is 'n virtuele adapter wat die kliënt skep wanneer 'n verbinding begin en verwyder wanneer dit eindig. 'n Handmatige ip link set oorleef dus presies so lank as die sessie waarop dit toegepas is, en die volgende verbinding begin met wat die kliënt ook al toeken. Op 'n masjien waar die kliënt versuim om die verwagte adres toe te pas, herhaal elke herverbinding dieselfde wanverhouding, en die huurkontrak of toegangsreël verwerp die toestel weer.

Daardie patroon is op sigself diagnosties. 'n Tonnel wat vir een sessie werk en by die volgende misluk, is nie 'n geloofwaardigheidsprobleem nie, want geloofsbriewe verander nie tussen verbindings nie.

Lees die waarde by die kliënt, nie by die koppelvlak nie

Die Linux-kliënt skryf onderhandelingsbesonderhede na sy ontfoutingslog, en die adres wat hy bedoel om te gebruik, verskyn daar as die laaste adresvormige teken van die verbindingsreeks. Vergelyk dit met wat die kern werklik hou, wat een readlink weg is: cat /sys/class/net/kvnet/address.

As die twee verskil, het die kliënt die regte waarde geken en versuim om dit toe te pas, en 'n haak wat dit toepas nadat die koppelvlak bestaan, maak die gaping toe. As die log glad geen adres bevat nie, is die probleem vroeër en hoort dit by die kliëntweergawe of die bedienerprofiel eerder as by 'n script.

Pas dit toe nadat die koppelvlak bestaan

NetworkManager-gebruikers kan 'n script in sy dispatcher-gids plaas en net optree wanneer die VPN-koppelvlak opkom. 'n Kliënt wat deur systemd bestuur word, verg meer sorg: 'n drop-in wat by diensbegin loop, aktiveer gewoonlik voordat die adapter bestaan, so die haak moet vir die koppelvlak wag eerder as om dit te veronderstel. Stel die adres dan, en as die kern weier terwyl die skakel op is, neem dit af, stel dit en bring dit terug op. Lees die onttrekte teken terug deur 'n MAC-patroon voordat jy dit aan ip link deurgee, sodat 'n onverwagte logreël nie 'n argument kan word nie.

Enigiets wat as root uit 'n kliënt se log loop verdien noue eienaarskap: 'n lêer wat deur root besit word, nie deur ander skryfbaar nie, en geen shell-interpolasie verder as die gevalideerde adres nie. Hou die patroonkontrole binne die script. Moenie toelaat dat loginhoud besluit watter opdrag loop nie.

Verifieer die huurkontrak eerder as die skakel

ip -4 -o addr show dev kvnet moet 'n adres in die verwagte reeks wys, ip neigh show dev kvnet moet die gateway wys, en een diens agter die VPN moet antwoord. Ontkoppel dan en verbind weer een keer; as die adres terugval, aktiveer die haak op die verkeerde gebeurtenis of glad nie.

'n Koppelvlak wat met die regte adres verskyn en nooit 'n huurkontrak kry nie, dui op die bedienerkant. Dit is 'n ander kontrole en gewoonlik 'n ander span. Bevestig dat die rekening toegelaat is en die poel steeds 'n adres het voordat jy die haak weer wysig.

Herkou die noodoplossing ná 'n opgradering

'n Kliëntbou wat die adres korrek stel, laat jou haak 'n verouderde waarde toepas, wat 'n nuwe fout is wat deur 'n regstelling ingebring is. Moet ook nooit 'n MAC van 'n ander masjien of 'n forumplasing kopieer nie; gebruik die waarde wat hierdie kliënt vir hierdie rekening log, en teken die datum aan waarop jy dit geverifieer het.

Hou die script kort genoeg om in een sitting te lees. Noodoplossings wat logs ontleed, is van nature tydelik. Die wat oorleef, is die wat 'n toekomstige leser kan verstaan sonder die oorspronklike draad.

Verwante artikels