Puuttuva VPN-reitti NetworkManagerissa: profiilin käytäntö vai skripti?

Yhdistät, tunnelin rajapinta ilmestyy, eikä yhtä tarvitsemaasi etuliitettä yksinkertaisesti ole taulukossa. Seuraava askel on yleensä etsiä skripti, joka lisää sen. Haku päätyy vastauksiin, jotka liittävät OpenVPN-apurin profiiliin, ja puolet niistä vastauksista pahentaa tilannetta parantamisen sijaan, koska puuttuvalla reitillä on kolme mahdollista omistajaa ja vain yksi niistä on puuttuva skripti.

Päätä, mikä omistaja on vastuussa, ennen kuin kirjoitat mitään.

Kolme omistajaa, yksi puuttuva etuliite

Etuliite voi puuttua siksi, ettei kukaan toimittanut sitä, siksi että profiili hylkäsi sen, tai siksi että se asennettiin paikkaan, jota et katsele. Ne ovat eri vikoja ja niillä on eri korjaukset.

Ensimmäinen on helpoin tarkistaa: tarjosiko palvelin tai liitännäinen reittiä koskaan? Taustajärjestelmä, joka ei koskaan saanut etuliitettä, ei voi asentaa sitä, eikä apuskripti voi keksiä saavutettavuutta, jota vastapuoli ei koskaan kuvannut. Toinen on profiilin käytäntö, joka voi tukahduttaa reittejä, jotka yhteys muuten ottaisi. Kolmas on taulukko tai sääntö, joka voi pitää reittiä paikassa, jota oletushaku ei koskaan konsultoi.

Neljäs omistaja olet sinä, myöhemmin: skripti, joka lisää reitin yhdistettäessä mutta ei poista sitä katkaistaessa. Se tuottaa etuliitteen, joka elää tunnelia pidempään, osoittaa kuolleeseen rajapintaan ja hämmentää seuraavaa koneen debuggaajaa.

Lue profiili ennen kuin lisäät mitään

Aloita tallennetun yhteyden omista ominaisuuksista. Lue ne vuotamatta salaisuuksia, ja käytä UUID:tä, jos profiilin nimi on monitulkintainen.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type kertoo sinulle, mikä taustajärjestelmä omistaa yhteyden, ja sillä on väliä, koska liitännäisen tiedot ovat taustajärjestelmäkohtaisia. Yhden liitännäisen hyväksymä avain ei ole toisen tuettu ohje, joten toisen asiakkaan dokumentaatiosta kopioitu pätkä ei ole todiste mistään.

ipv4.ignore-auto-routes ja ipv4.never-default vastaavat eri kysymyksiin. Ensimmäinen voi hylätä reittejä, jotka yhteys muuten ottaisi automaattisesti, ja toinen hallitsee sitä, voiko profiilista tulla oletusreitti. Profiili, joka jättää automaattiset reitit huomiotta eikä luota mihinkään muuhun, yhdistyy siististi eikä asenna juuri mitään.

ip -4 rule show
ip -4 route show table all

Nämä kaksi komentoa ratkaisevat kolmannen mahdollisuuden. Etsi etuliitettäsi jokaisesta taulukosta, ei vain mainista, ja tarkista, lähettääkö käytäntösääntö asiaankuuluvan haun muualle. Jos etuliite on toisessa taulukossa eikä mikään konsultoi sitä, sinulla ei ole puuttuvaa reittiä; sinulla on haku, joka ei koskaan saavuta sitä.

Mitä skripti ei voi korjata

Apuskriptin lisääminen antaa NetworkManagerin vpn.data-kentälle ohjelman suoritettavaksi. Se on todellinen mekanismi, ja se on väärä useimpiin näistä tapauksista, koska skripti saa hallinnan sen jälkeen, kun profiilin oma käytäntö on jo päättänyt, mitä hyväksytään.

OpenVPN:n script-security on toinen toistuva sekaannus. Se on OpenVPN-asetus, joka määrää, mitä skriptejä asiakas saa suorittaa ja mitä se saa laittaa niiden ympäristöön; taso 3 sallii tunnistetietojen välittämisen ympäristön kautta, mikä on salaisuuksien käsittelyä koskeva päätös eikä reitityksen korjaus. Sen liittäminen profiiliin, jonka taustajärjestelmä ei ole OpenVPN, tai sen nostaminen, kun mikään skripti ei tarvitse sitä, lisää altistusta lisäämättä reittiä.

Sitten on uudelleenkäynnistyksen refleksi. NetworkManager-palvelun uudelleenkäynnistys repii alas ja rakentaa uudelleen jokaisen hallitun linkin, myös sen, jonka kautta olet yhteydessä, jos työskentelet etänä. Se on häiritsevä toimenpide, ei harmiton diagnostiikka, ja palvelimella se voi olla ero hengissä säilyvän istunnon ja sellaisen välillä, joka ei säily.

Päätös, järjestyksessä

Esitä kolme kysymystä peräkkäin. Toimittiko vastapuoli etuliitteen, minkä taustajärjestelmän loki tai sen oma tilatuloste näyttää? Jos kyllä, onko profiili määritetty hyväksymään ja asentamaan reittejä vai tukahduttaako se ne? Jos reitti on olemassa jossain, onko hakupolku oikea testaamallesi liikenteelle?

Vasta kun ensimmäinen vastaus on kyllä, toinen on kyllä ja kolmas on oikein, täydentävästä skriptistä tulee puolustettava, ja silloinkin sinun pitäisi kysyä, tukeeko taustajärjestelmä reittiä natiivisti. VPN-asetusten viite dokumentoi service-type ja liitännäiskohtaisen tietosanakirjan, ja sieltä kannattaa aloittaa ennen kuin olettaa avaimen olevan olemassa.

Hyväksytyn korjauksen jälkeen yhdistä uudelleen ja testaa kohde osoitteella ja sitten nimellä, katkaise sitten yhteys ja yhdistä uudelleen varmistaaksesi, että tila on toistettavissa. Yksi omistaja, yksi taulukko ja reitti, joka katoaa tunnelin mukana, on tulos, joka kannattaa saada.