Toimittajan VPN-sovellus vastaan NetworkManager: kuka omistaa tilan?
Profiili nimeää liitännäisen, ei toimittajan asiakasohjelman käytöstä. Kartoita, kuka omistaa rekisteröinnin, DNS:n, eston ja päivitykset ennen kuin vaihdat hallitun kannettavan.
Profiilin tuominen ei ole sama asia kuin asiakasohjelman korvaaminen. NetworkManager tallentaa liitännäistyypin yhdessä liitännäiskohtaisten tietojen ja salaisuuksien kanssa, ja liitännäinen, joka omistaa kyseisen tyypin, päättää, mitä yhteys voi tehdä. Kaikki, mitä toimittajan sovellus kerrostaa sen päälle, rekisteröinnistä pysyvään estoon, elää tiedoston ulkopuolella. Onko vaihto turvallinen, riippuu siitä, mihin näistä kerroksista todella luotat.
Tiedosto nimeää liitännäisen, ei ominaisuusjoukkoa
NetworkManagerin VPN-asetusten viite kuvaa palvelutyypin, joka valitsee liitännäisen, sekä läpinäkymättömän tietosanaston ja salaisuuksien sanaston, joita vain liitännäinen tulkitsee. Profiili on sopimus yhden toteutuksen kanssa, ei kuvaus käytöksestä, jonka mikä tahansa asiakasohjelma voi toistaa. Kaksi asiakasohjelmaa voi puhua samaa protokollaa ja silti erota siinä, mitä ne neuvottelevat ja mitkä datapolut ne ottavat käyttöön. Protokollan nimi kertoo, mikä tunneli on, ei koskaan sitä, mitä ympäröivä asiakasohjelma tekee sillä.
Vertaa siis vaatimuksia, älä kääreitä. Kysymys ei ole siitä, saako vaihtoehto yhteyden, koska yleensä saa; kysymys on siitä, säilyykö jokainen vaatimus, joka teki alkuperäisestä asiakasohjelmasta hyväksyttävän, siirrossa. Kirjoita ne vaatimukset muistiin ennen kuin asennat mitään, muuten vertailusta tulee metsästystä sen perään, mikä hajoaa ensin.
Mikä toimittajan sovellus lisää tunnelin ympärille
Toimittajien asiakasohjelmat niputtavat yleensä rekisteröinnin ja laitteen tilan tarkistukset, toisen tekijän kulun omalla käyttöliittymällään, pysyvän eston, päivityskanavan ja tukityökalut. Osa siitä seisoo protokollan vieressä, ja osa on erillinen tuote, joka vain jakaa asentajan. NetworkManager voi korvata tunnelin ja sen reitityksen, ja dispatcher-skriptit voivat laukaista toimintoja, kun yhteyden tila muuttuu. Se ei kuitenkaan toista estomoottoria, varmenteen uusinnan kulkua tai oletusta siitä, kuka käyttäjä saa nostaa yhteyden.
Useampi komponentti ei tarkoita turvallisempaa, eikä vähempi tarkoita heikompaa. Kysymys on siitä, mikä komponentti toimeenpanee sen käytännön, jota sinua pyydettiin noudattamaan. Jos auditoija kysyy, mikä estää liikenteen tunnelin pudotessa, vastauksen on nimettävä jotain, joka todella tekee sen, eikä vain yhteyden muodostava profiili ole se vastaus.
Missä omistajuus todella eroaa
Lue tämä omistajuuskarttana äläkä tarkistuslistana, sillä alla olevat epäonnistumiset ovat omistajuuden aukkoja eikä mikään määrä asiakasohjelman asetuksia sulje niitä. Jokainen rivi nimeää kerroksen, osapuolen, joka yleensä pitää sitä tänään, ja sen, missä aukko näkyy ensin.
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
Yhdistä jokaiseen riviin havainto, jonka voit toistaa, älä tunnetta asiakasohjelmasta. Aiottuun ratkaisijaan kautta ratkennut nimi, reitti, joka katoaa tunnelin pysähtyessä, ja estetty yhteys simuloidun katkoksen jälkeen ovat kolme havaintoa, jotka yhdessä kattavat suurimman osan taulukosta. Kirjoita havainto sen vaatimuksen viereen, jonka se todistaa, ja pidä epäonnistuneet, sillä epäonnistunut havainto on ainoa osa kirjausta, joka ennustaa seuraavan tapauksen.
Vaihto ilman päällekkäistä omistajuutta
Toimittajan asiakasohjelman ja saman palvelun NetworkManager-yhteyden ajamien samanaikaisesti on yleisin tapa, jolla nämä vertailut menevät pieleen. Molemmat asentavat reittejä, molemmat voivat asettaa DNS:n ja molemmat voivat koskea palomuurin tilaan. Se, mitä silloin mittaat, on kolmas järjestely, joka ei vastaa kummankaan asiakasohjelman dokumentoitua käytöstä.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"Ensimmäinen komento kertoo, onko profiili ylipäätään VPN-tyyppiä. Toinen näyttää liitännäisen palvelutyypin ja mitkä salaisuudet on tallennettu, millä on merkitystä, kun avainta odotetaan agentilta tiedoston sijaan. Lokikirja on paikka, jossa liitännäinen, joka latautui mutta ei pystynyt neuvottelemaan, kertoo siitä. Jos mikään kolmesta ei näytä ongelmaa, aukko on tunnelin yläpuolisissa käytäntökerroksissa eikä yhteydessä.
Irrota vanha asiakasohjelma ennen uuden yhteyden ottamista käyttöön, pidä päätepisteet ja tili samoina ja kirjoita muistiin, mikä komponentti omistaa reitit, ratkaisijan asetukset ja eston. Juuri se muistiinpano estää seuraavaa päivitystä päättymästä kahteen omistajaan.