’n VPN-sekondêre hoort by een Wi-Fi-profiel, nie by almal nie

Stel ’n VPN as ’n sekondêre van die tuis-Wi-Fi-verbinding op en alles werk, totdat die skootrekenaar by ’n ander toegangspunt aansluit en die tonnel af bly. Die nuwe verbinding is ’n aparte konfigurasie-objek met sy eie UUID, en dit het geen rede om van die band te weet wat jy vir sy voorganger geskep het nie. Niks het fout gegaan nie; die assosiasie het bloot nooit bestaan nie.

NetworkManager se verbindingverwysing definieer sekondêres as UUID's wat saam met ’n bepaalde basisverbinding aktiveer. Dit merk ook op dat gewone VPN-profiele nie outomatiese aktivering soos basisverbindings implementeer nie. Albei stellings lei tot dieselfde gevolgtrekking: die assosiasie is per profiel, en iemand moet dit vir elke nuwe een skep.

Wat ’n sekondêre werklik is

’n Basisverbinding het ’n identiteit, ’n UUID en ’n lys sekondêres. Wanneer dit aktiveer, aktiveer die bestuurder ook daardie sekondêres in volgorde, en dit is hoe ’n VPN ’n Wi-Fi-netwerk volg sonder ’n handmatige klik. Die verhouding woon op die basisverbinding, geskryf as UUID-stringe eerder as name. Daardie keuse van voorstelling is nie toevallig nie; dit is wat die assosiasie ’n hernoeming laat oorleef.

Daardie detail oor name maak meer saak as wat dit lyk. Om ’n VPN-profiel te hernoem laat sy UUID ongeraak, so bestaande assosiasies bly werk. Om die ou profiel te verwyder en ’n nuwe een in te voer lewer ’n nuwe UUID, en elke assosiasie wat na die oue gewys het, wys nou na niks.

Ondersoek die bestaande lys voordat jy byvoeg. ’n Tuisprofiel met een sekondêre is nie ’n reël wat elke SSID pas nie; dit is een ry in een objek, en dit sal nie geraadpleeg word wanneer ’n ander basis aktiveer nie.

Plaas die assosiasie waar profiele geskep word

Op ’n persoonlike masjien, maak die koppeling van die beoogde sekondêre deel van die byvoeging van elke toegelate Wi-Fi-profiel. Dit is ’n gewoonte eerder as ’n funksie, maar dit is ’n gewoonte wat ’n konsekwente toestand lewer, en dit neem een opdrag of twee dialoogbesoeke per netwerk. Hou ’n kort nota van watter netwerke die tonnel moet dra, want die lys is die beleid.

Op bestuurde toestelle, laat die voorsieningswerkvloei die Wi-Fi-inskrywing en sy VPN-assosiasie in dieselfde stap skep, en pas dieselfde behandeling toe op toegelate profiele wat reeds bestaan. Om ’n VPN-profiel op sy eie te versprei laat die basisverhoudings onbepaald, en dit is hoe ’n vloot ’n tonnel kry wat net die helfte van die skootrekenaars gebruik.

Waar gebruikers steeds profiele buite die bestuurde pad kan skep, besluit uitdruklik wat met daardie inskrywings gebeur. Om aan te neem dat hulle ’n assosiasie erf, is nie ’n beleid nie; dit is ’n hoop met ’n ondersteuningskoste daaraan verbonde.

Beplan vir die verandering van die VPN se identiteit

Die voorsieningsbron het die beoogde VPN se UUID nodig, nie ’n vertoonnaam wat iemand geraai het nie. Wanneer instandhouding daardie VPN met ’n vars ingevoerde objek vervang, werk die voorsieningsjabloon en die geaffekteerde bestaande assosiasies in dieselfde verandering by. ’n Hernoeming is nie ’n vervanging nie, en om die twee as gelykwaardig te behandel, is hoe ’n werkende uitrol ’n week later breek.

Stoor die UUID langs die rede waarom dit bestaan. ’n Toekomstige ingenieur wat ’n blote UUID in ’n sekondêre lys vind, het geen manier om te sê of dit aktueel is nie, en sal dit waarskynlik verwyder terwyl hy opruim.

Aktivering is nie handhawing nie

’n Sekondêre versoek gebeur op aktiveringstyd. Dit blokkeer nie toepassings gedurende die interval voordat verifikasie voltooi is nie, en dit stop nie verkeer nadat die tonnel misluk nie. Dit is verskillende eienskappe, verskaf deur verskillende meganismes, en om hulle te verwar lewer ’n ontwerp wat streng in die profiel lyk en in die praktyk toegeeflik is.

Om direkte verkeer te blokkeer is ’n aparte funksie met sy eie konfigurasie en sy eie mislukkingsmodusse, en dit moet rekening hou met die verkeer wat die netwerk moet bereik voordat enige tonnel kan bestaan: vasgevangde portale, aanmeldbladsye, die eindpunt self. ’n Blokkeringsbeleid wat nie voor verifikasie bevredig kan word nie, sluit die masjien uit van die netwerk wat dit nodig het.

Plaas daardie onderskeid in die instruksies wat gebruikers werklik lees. ’n Nuwe Wi-Fi-netwerk kan die tonnel aanvra; handhawing besluit of enigiets mag uitgaan wanneer dit nie kan verbind nie. Gebruikers wat net die eerste helfte vertel word, sal die ontwerp as stukkend rapporteer.

Toets met ’n werklik nuwe profiel

Gebruik ’n goedgekeurde toetsnetwerk en ’n nuutgeskepte basisprofiel, nie die tuisinskrywing wat reeds werk nie. Kyk in volgorde na die basisaktivering, die versoekte sekondêre UUID en enige verifikasie-oproep, en let op watter stadium vasval wanneer dit vasval. ’n Geheime agent wat ná lessenaar-aanmelding beskikbaar word, is nie outomaties in elke opstartkonteks daar nie, so ’n herbegin hoort in die toetsplan. Kontroleer dan die beoogde hulpbron en die mislukkingspad: kom die tonnel op voordat die toepassing dit nodig het, en wat gebeur met daardie toepassing wanneer verifikasie misluk?

Kontroleer dan die beoogde hulpbron en die mislukkingspad: kom die tonnel op voordat die toepassing dit nodig het, en wat gebeur met daardie toepassing wanneer die tonnel nie kan verifieer nie? Daardie twee waarnemings is die aanvaardingskriteria, en nie een van hulle is in die profiel self sigbaar nie.