Eelnevalt loodud tun OpenVPN-is: kahe omandimudeli võrdlus
Eelnevalt loodud tun-liidest saab uuesti kasutada, kuid ainult üks komponent peaks omama selle aadresse ja marsruute. Võrrelge kahte mudelit enne ifconfig-noexec lisamist.
Keegi lõi eelnevalt tun1, profiil ütleb dev tun1, ja ühendus ei kinnitu ikka. Nime olemasolu hostis ei ütle peaaegu midagi, sest kinnitumine sõltub nimeruumist, seadme tüübist, lüli omanikust ja sellest, mida deemoni lubatakse teha. Seadme korduskasutus sunnib ka otsust, mille vaikekonfiguratsioon peidab: milline komponent kirjutab aadressid ja marsruudid. Kahe korralduse rikkerežiimid erinevad palju rohkem kui konfiguratsiooniread, seega otsustage enne profiili muutmist.
Nimi ei ole kinnitumine
dev tun1 küsib OpenVPN-ilt seda nimega liidest ja traditsioonilised kasutajaruumi koosteet üritavad selle avada. Kui nimi ei järgi tavapärast tun- või tap-mustrit, vajab profiil ka vastavat dev-type-i, sest tüüpi ei tuletata kunagi stringist. TAP-seade ei ole teise sildiga TUN-seade: vale seadme kinnitamine kas ebaõnnestub kohe või loob lüli, mis kannab kaadreid, mida keegi ei oota. Kontrollige tüüpi enne kõike muud, sest iga järgnev kontroll eeldab, et mõlemad pooled on selles ühel meelel. Seejärel veenduge, et protsess suudab seadme tõesti avada, mitte ainult seda näha.
dev tun1
dev-type tun
Võrguliides ja /dev/net/tun on eri objektid: üks on lüli nimeruumi sees, teine on märgiseade, mida kasutajaruumi programm kinnitumiseks kasutab. Linuxi TUN/TAP dokumentatsioon kirjeldab seda kinnitumisteed ja püsiseadmete omandireegleid. Juurkest, mis suudab käivitada ip link, tõestab ainult, et kestal on õigused, mitte et daemonil need on. Seadmesõlme omand, teenuse võimekuste hulk ja kasutaja, kellena see töötab peavad kõik klappima enne, kui avamine õnnestub.
Seade, mis on olemas ja mida ei saa avada, on omandiprobleem, mitte marsruutimisprobleem. Käsitlege seda nii ka silumise ajal, muidu kulub pärastlõuna marsruutitabelite lugemisele, mis ei olnud kunagi probleem.
Kes lüli konfigureerib: kaks omandimudelit
Esimeses mudelis konfigureerib OpenVPN aadressid ja marsruudid ühenduse ülesvõtmise osana. See on vaikekäitumine ja kõige kergemini mõistetav, sest üks komponent loob oleku ja eemaldab selle jälle. Teises mudelis omab liidest väline haldur ja ifconfig-noexec takistab OpenVPN-il oma aadressikonfiguratsiooni käske käivitamast ning annab parameetrid hoopis skriptidele. Seejärel peab haldur ise rakendama õige kohaliku ja partneri konfiguratsiooni, mis on rohkem tööd, kui valiku nimi vihjab. Kahe vahel valimine on küsimus sellest, kes tohib lüli muuta, kui see on üleval.
ifconfig-noexec katab ainult aadressid: marsruutimistabel jääb puutumata ja marsruutide konfiguratsioon kuulub route-noexec-le. Käsitlege kahte direktiivi eraldi juhtelementidena eraldi omanikega, sest ühe seadmine ja teise eeldamine on poolikult konfigureeritud lülide tavaline allikas. Valige täpselt üks omanik kihi kohta, aadressid ühte kohta ja marsruudid ühte kohta. Kui võrguhaldur ja VPN-abiline kirjutavad mõlemad aadresse, siis just nii kustutab katkestus oleku, millest teine pool ikka sõltub.
Uurige seadet sellest nimeruumist, mis on oluline
Uurige seadet nimeruumist, milles VPN-protsess töötab, mitte sellest, milles teie kest juhtub olema. Kaks allolevat käsku vastavad eri küsimustele ja erinevus ilmneb siis, kui host näeb liidest, mida konteiner ei näe. Käivitage need antud järjekorras, sest teisel on mõtet alles siis, kui teate, kas lüli üldse olemas on.
ip -details link show dev tun1
ip tuntap show
Esimene käsk prindib lüli nii, nagu tuum seda näeb, koos lippude ja liidese tüübiga, ja nii kinnitate, et see on seade, mida mõtlesite. Teine loetleb püsivaid tun/tap-kirjeid, mis on olemas ilma, et miski protsess neid hoiaks. Liides, mis ootab oma määratud omanikku, on teine olukord kui teise VPN-i külge kinnitatud elav tunnel, ja ainult teine selgitab, miks teie enda kinnitumine ebaõnnestub. Leidke seadet hoidev protsess enne, kui midagi muudate, sest püsikirjel ja hõivatud liidesel on erinevad lahendused.
Mitme järjekorra tugi on kindel draiverikorraldus oma nõuetega, mitte luba seotud protsessidel ühte liidest jagada. Teise omaniku elav sessioon on koordineerimisprobleem ja ükski profiilimuudatus seda ei lahenda.
Kaks erinevat püsivuse liiki
Tuuma püsivus ja persist-tun kirjeldavad eluigasid, mida on lihtne segi ajada ja kulukas eksida. Püsiseade on olemas igast protsessist sõltumatult, seega jääb see peatumise üle ja järgmine start saab seda uuesti kasutada. persist-tun hoiab ressursse ühe OpenVPN-i protsessi sees toetatud pehmete lähtestuste ajal, palju lühem horisont. Kumbki ei luba, et teenuse peatamine jätab marsruudid ja aadressid paigale, ja nähtavale jääv liides ei ole tõestus töötavast krüpteeritud sessioonist.
Kinnitage ka taustaprogramm, sest eelnevalt loodud liides ei ütle midagi selle kohta, milline teostus selle avab. Otsese andmeteega kogukonnabuildid üritavad seda kasutada, kui disain ei ütle teisiti. Kus versioon seda lülitit toetab, valib disable-dco hoopis kasutajaruumi tee; vanematel mootoritel ja teistel klientidel sellist direktiivi ei ole, seega hoidke versioonitingimus valiku kõrval, mitte ärge eeldage, et see kehtib.
Mis läheb katki, kui testida ainult käivitust
Omandikokkulepe võib läbida esimese testi ja kukkuda viimases, mis teeb käivituse üksinda nõrgaks kontrolliks. Jälgige selle asemel kahte üleminekut: pehme lähtestus ja täielik peatus, millele järgneb start.
systemctl status openvpn-client@lab
ip -details link show dev tun1
Käivitus on lihtne juhtum: üksus tõuseb, lüli ilmub ja olekuväljund nimetab laaditud profiili. Kinnitumine on hetk, mil daemon seadme avab, seega käivitage lüli kontroll pärast seda, kui üksus teatab aktiivsusest, mitte enne. Kui lüli on olemas, samal ajal kui olek alles aktiveerub, vaatate püsiseadet, mille külge keegi pole veel kinnitunud, mitte töötavat tunnelit. Laske lüli kaudu läbi tõeline liiklus enne edasiminekut, sest kinnitatud liides ilma kasutatava marsruudita on ikka ebaõnnestumine.
kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1
Pehme lähtestus peaks jätma sessiooni kasutatavaks ja ressursid terveks, ja seda tööd teeb persist-tun. Täielik peatus on koht, kus väline haldur end paljastab: kui lüli või selle aadressid peatumise üle elavad, omab neid keegi teine, ja see on kas dokumenteeritud olek või viga, mille just leidsite. Kirjutage mõlemad tähelepanekud profiili kõrvale, et järgmine muudatus algaks tõenditest, mitte diagrammist.