ifconfig-noexec neišsaugos jūsų SSH sesijos: ką jis iš tikrųjų daro
Jis slopina pačios OpenVPN sąsajos adreso konfigūraciją. Jis nerezervuoja SSH atsakymo maršruto, neišjungia visų maršruto pakeitimų ir nepateikia trūkstamo adreso.
Vienoje forumo temoje ifconfig-noexec siūloma kaip sprendimas, kuris išlaiko SSH sesiją gyvą, kai pakyla tunelis. Samprotavimas skamba įtikinamai, kol nepažiūri, ką ši parinktis iš tikrųjų liečia. Ji neleidžia OpenVPN sukonfigūruoti tunelio sąsajos adreso ir tuos duomenis perduoda scenarijams; apie tai, kur keliauja atsakymai į jūsų valdymo ryšį, ji nieko nesako. Tikėjimas priešingai sukuria tunelį be naudojamo adreso ir SSH sesiją, kuri vis tiek miršta.
Ką ši parinktis iš tikrųjų perduoda
Pagal nutylėjimą klientas pakelia tunelio įrenginį ir priskiria vietinį bei nuotolinį adresus, kuriuos jam davė serveris. Kai ifconfig-noexec nustatyta, šis žingsnis praleidžiamas, o suderintos reikšmės eksportuojamos į scenarijaus aplinką, kad kažkas kitas galėtų jas pritaikyti.
Nuosavybė pereina. Jos vietoje nieko neišgalvojama.
Taigi klausimas, į kurį parinktis atsako, yra kas konfigūruoja sąsają, o klausimas, į kurį ji neatsako, yra kaip paketai randa kelią atgal pas jus. Laikykite šiuos du dalykus atskirai, kitaip praleisite visą vakarą redaguodami maršrutus, kad kompensuotumėte sąsają be adreso.
Trys panašios parinktys su skirtingomis užduotimis
Šią šeimą lengva supainioti, nes pavadinimai skiriasi vienu žodžiu, o simptomai persidengia. Prieš rinkdamiesi bet kurią, perskaitykite, ką kiekviena slopina.
| Option | What stops happening |
|---|---|
ifconfig-noexec | OpenVPN's own tunnel-address configuration; values go to scripts instead |
route-noexec | Automatic route addition and removal; route details go to a script |
route-nopull | Server-pushed routes and related options such as DNS are rejected |
Tai alternatyvos, kurias reikia suprasti atskirai, o ne rinkinys, kurį reikia suklijuoti. Adreso konfigūracijos slopinimas neslopina maršruto pakeitimų, ugniasienės taisyklių ar stumiamų parinkčių, kurios perneša DNS. Deleguotas scenarijus taip pat gali laisvai keisti maršrutus, o tai yra sprendimas, kurį perduodate, o ne išvengiate.
Jei tiekėjo klientas apgaubia variklį, naudokite jo palaikomą integraciją, o ne meskite žemo lygio direktyvą į profilį ir tikėkitės, kad apvalkalas jos paisys. Apvalkalai dažnai iš naujo generuoja profilį prisijungiant, todėl rankinis pakeitimas dingsta be klaidos. Prieš praleisdami vakarą prie failo, patikrinkite, kur klientas laiko savo nustatymus. Tai galioja kiekvienai lentelės eilutei, ne tik tai, dėl kurios atėjote.
SSH sesija, kurią ketinote apsaugoti
SSH ryšys turi šaltinio adresą, paskirties adresą ir atsakymo kelią. Serveryje, kuriame ką tik įdiegtas viso tunelio numatytasis maršrutas, atsakymas į jūsų viešąjį adresą sutampa su tuneliu, ir VPN šliuzas jį numeta.
Niekas tunelio sąsajos adreso konfigūracijoje to nekeičia.
Tai sutvarko konkretesnis maršrutas jūsų valdymo adresui per prieš tunelį buvusį šliuzą, arba politikos taisyklė, kuri nukreipia tą srautą, be to, filtro nustatymai, kuriuos taiko jūsų pagrindinis kompiuteris. Abi problemos kartais pasirodo kartu, ir taip viena supainiojama su kitos gydymu. Išbandykite jas atskirai: pakelkite tunelį be parinkties, pažiūrėkite sąsajos adresą ir atsakymo kelią, tada nuspręskite, kuri iš dviejų iš tikrųjų sulaužyta.
Ką turi perimti deleguotas scenarijus
Jei tikrai norite, kad sąsają konfigūruotų kitas savininkas, išvardykite darbą: pritaikykite vietinį ir nuotolinį adresus, pakelkite įrenginį, atkurkite arba pašalinkite adresavimą išjungiant ir padarykite tą patį dar kartą po pakartotinio prisijungimo. Vienos sėkmingos sesijos reikšmių negalima užkoduoti kietai, nes serveris kitą kartą gali duoti kitą porą.
Kliento eksportuojami aplinkos kintamieji yra vienintelė palaikoma to darbo įvestis.
env | grep -E '^ifconfig_|^route_'Bet kuriame route-up scenarijuje tie kintamieji yra prieinami; iš cron užduoties ar rankinės shell sesijos ne. Patvirtinkite, kurį gyvavimo ciklo kabliuką naudoja jūsų versija, ir patvirtinkite, kad kabliukas veikia su pakankamomis teisėmis pakeisti sąsają, nes klientas jau gali būti perėjęs prie neprivilegijuoto naudotojo.
Išbandykite visą gyvavimo ciklą, o ne vieną sesiją
Pakelkite tunelį, patikrinkite įrenginio adresą, tada prisijunkite iš naujo ir patikrinkite dar kartą. Konfigūracija, kuri veikia vieną kartą ir nepavyksta antruoju bandymu, paprastai reiškia, kad deleguotas žingsnis vykdomas tik per pirmąjį prisijungimą.
Tada patikrinkite abu priėmimo kriterijus kartu: naujas SSH ryšys per numatytą valdymo kelią veikia, o leidžiama programa teisingai naudoja tunelį.
Sena SSH sesija, kuri atsitiktinai išlieka gyva, kai tunelis neturi adreso, nėra sėkmė, ir būtent tokią būseną sukuria ši parinktis, kai niekas neperima darbo. Pirmiausia patikrinkite sąsajos adresą, tada valdymo atsakymo kelią, tada programą. Jei du iš trijų neteisingi, parinktis perkėlė darbą, bet nesuteikė jam savininko.