Ar šis NetworkManager papildinys gali vienu metu paleisti du VPN?

Jungčių sąraše yra du VPN įrašai, abu teigia prisijungę, o laukiamą srautą siunčia tik vienas iš jų. Arba antrasis visai atsisako startuoti, ir niekas negali pasakyti, ar kaltas papildinys, klientas, ar pamiršta taisyklė. Teiginiai apie vieno VPN ribą aprašo konkrečias implementacijas, o implementacijos skiriasi. Pirmiausia patikrinkite galimybę, paskui derinimą.

Suskaičiuokite išsaugotus profilius, paskui aktyvavimus

Išsaugotas profilis yra konfigūracijos objektas, o aktyvi jungtis yra veikianti instancija. Sąrašas vizualiai sujungia dvi sąvokas, todėl abi ataskaitos skamba teisingai. Pradėkite nuo tikslių objektų įvardijimo jų UUID, nes rodomas pavadinimas nėra unikalus ir senas importas dažnai dalijasi žyme su naujesniu įrašu. Tada atskirai patikrinkite aktyviųjų sąrašą ir pažiūrėkite, kurie UUID pasirodo. Tik tada žinosite, ar lyginate dvi konfigūracijas, ar du gyvus tunelius.

To paties UUID aktyvavimas du kartus yra trečias atvejis ir tai ne lygiagretumas. Tai vienos instancijos pakartotinis aktyvavimas.

Perskaitykite paties papildinio metaduomenis

Kiekvienas VPN papildinys pateikia nedidelį metaduomenų failą, kurį skaito tvarkyklė, ir tie failai gali deklaruoti, ar papildinys palaiko kelias jungtis vienu metu. Skaitykite šioje mašinoje įdiegtą failą, o ne kartokite tai, ką šiuo metu rašo upstream projektas, nes platinimo paketas nusprendžia, ką iš tikrųjų turite. Ta pati patikra galioja kiekvienam protokolui: atsakymas apie vieną papildinį nieko nesako apie kitą. Užrašykite paketo versiją šalia rezultato, kad vėlesnis palyginimas ką nors reikštų.

Seni patarimai apie vieno VPN ribą aprašė senesnes integracijas. Tai nėra amžinai tiesa ir nėra saugu laikyti fiksuota, o failas priešais jus tai išsprendžia vietoje.

Lygiagretus nereiškia suderinto

Dviejų papildinių sėkmingas paleidimas įrodo galimybę, o ne dizainą. Du tuneliai, kurie abu siūlo numatytąjį maršrutą, konkuruos, ir tas, kuris savo maršrutą įdiegė paskutinis, paprastai laimi to neskelbdamas. Persidengiantys privatūs diapazonai turi tą pačią problemą mažesne forma.

Nuspręskite, kurie tikslai priklauso kuriam profiliui, prieš ką nors aktyvuodami. Profilio pervadinimas neišskiria tikslų.

DNS išrenka nugalėtoją, nesvarbu, ar jūs tai darote

Sprendėjo nustatymai yra pagal profilį, o kai du aktyvūs, sprendimo tvarką lemia taisyklė ir prioritetas, o ne ketinimas. Paskutinis pakilęs profilis gali tyliai valdyti kiekvieną įmonės vardą.

Priskirkite kiekvieną privatų vardų sritį tam sprendėjui, kuris turėtų už ją atsakyti, ir maršrutizavimo pirmenybę nustatykite sąmoningai, o ne pasikliaukite tvarka. Tada išbandykite vardą iš kiekvienos srities, kai abu tuneliai pakelti, ir dar kartą, kai vienas jų atjungtas. Sprendėjas, kuris veikia tik tol, kol pakelti abu tuneliai, yra dizainas, kuris ką nors nustebins pačiu netinkamiausiu momentu.

Diegkite fiksuota tvarka ir tikrinkite tarp žingsnių

Aktyvuokite vieną profilį, patikrinkite jo maršrutų ir sprendėjo būseną, tada aktyvuokite antrą ir patikrinkite vėl. Dviejų būsenų palyginimas pasako, kas pasikeitė ir kuris profilis ką valdo. Neaktyvuokite abiejų ir tada diagnozuokite rezultatą.

Išbandykite kiekvieną reikalingą išteklių per tunelį, kuris turėtų jį nešti, tada atjunkite vieną profilį ir patvirtinkite, kad kitas išlaiko savo maršrutus, savo DNS ir numatytą gedimo elgseną. Jei įdiegtas papildinys tikrai negali padaryti to, ko reikia, rinkitės palaikomą atnaujinimą arba aiškiai izoliuotą alternatyvą, o ne atgaivinkite pasenusį protokolą šalia tvarkyklės. Antras, atskiras tunelis, kurio niekas nevaldo, nėra izoliacija; tai dar vienas netikėtų maršrutų šaltinis.