ifconfig-noexec ne savos vian SSH-sesion: kion ĝi faras
Ĝi subpremas la propran agordon de la interfaca adreso fare de OpenVPN. Ĝi ne rezervas respondvojon por SSH, ne malŝaltas ĉiun vojŝanĝon kaj ne liveras la mankantan adreson.
Ie en forumfadeno, ifconfig-noexec estas proponita kiel la ripeto kiu tenas SSH-sesion vivan kiam tunelo ekfunkcias. La rezonado ŝajnas kredebla ĝis vi kontrolas kion tuŝas la agordo. Ĝi malhelpas al OpenVPN agordi la adreson de la tunela interfaco kaj transdonas tiujn valorojn al skriptoj anstataŭe; pri tio, kien iras respondoj al via administra konekto, ĝi diras nenion. Kredi la malon produktas tunelon sen utiligebla adreso kaj SSH-sesion kiu tamen mortas.
Kion la agordo fakte delegas
Defaŭlte, la kliento levigas la tunelan aparaton kaj atribuas la lokan kaj malproksiman adresojn kiujn la servilo donis al ĝi. Kun ifconfig-noexec agordita, tiu paŝo estas preterpasata, kaj la intertraktitaj valoroj estas eksportitaj al la skripta medio por ke io alia apliku ilin.
La posedo moviĝas. Nenio estas elpensita en ties loko.
Do la demando kiun la agordo respondas estas kiu agordas la interfacon, kaj la demando kiun ĝi ne respondas estas kiel pakoj trovas la vojon reen al vi. Tenu tiujn aparte, aliokaze vi pasigos vesperon redaktante vojojn por kompensi interfacon sen adreso.
Tri similaj agordoj kun malsamaj taskoj
La familio estas facile konfuŝebla ĉar la nomoj diferencas per unu vorto kaj la simptomoj interkovriĝas. Legu kion ĉiu subpremas antaŭ ol elekti iun ajn.
| Agordo | Kio ĉesas okazi |
|---|---|
ifconfig-noexec | La propra agordo de tunela adreso fare de OpenVPN; valoroj iras anstataŭe al skriptoj |
route-noexec | Aŭtomata aldono kaj forigo de vojoj; detaloj de la vojo iras al skripto |
route-nopull | Vojoj puŝitaj de la servilo kaj rilataj agordoj kiel DNS estas rifuzataj |
Tiuj estas alternativoj komprenendaj unuope, ne aro por kunglui. Subpremi adresagordon ne subpremas vojajn ŝanĝojn, fajrmurajn regulojn aŭ la puŝitajn agordojn kiuj portas DNS. Delegita skripto ankaŭ estas libera ŝanĝi vojojn, kaj tio estas decido kiun vi transdonas anstataŭ eviti.
Se vendista kliento envolvas la motoron, uzu ĝian subtenatan integriĝon anstataŭ ĵeti malaltnivelan direktivon en profilon kaj esperi ke la volvilo respektos ĝin. Volviloj ofte regeneras la profilon dum konekto, do permana redakto malaperas sen eraro. Kontrolu kie la kliento tenas siajn agordojn antaŭ ol pasigi vesperon pri la dosiero. Tio validas por ĉiu vico en la tabelo, ne nur por tiu pro kiu vi venis.
La SSH-sesio kiun vi volis protekti
SSH-konekto havas fontan adreson, celan adreson kaj respondan vojon. Sur servilo kiu ĵus instalis tutunan defaŭlton, la respondo al via publika adreso kongruas kun la tunelo, kaj la VPN-pordego forĵetas ĝin.
Nenio en la adresa agordo de la tunela interfaco ŝanĝas tion.
Tion riparas pli specifa vojo por via administra adreso tra la pordego antaŭ la tunelo, aŭ politika regulo kiu gvidas tiun trafikon, plus la filtragordoj kiujn via gastiganto aplikas. La du problemoj foje aperas kune, kaj tiel oni prenas unu kiel kuracilon por la alia. Testu ilin aparte: levigu la tunelon sen la agordo, rigardu la interfacan adreson kaj la respondan vojon, kaj tiam decidas kiu el la du estas fakte rompita.
Kion delegita skripto devas transpreni
Se vi vere volas ke alia posedanto agordu la interfacon, listigu la laboron: apliku la lokan kaj malproksiman adreson, levigu la aparaton, restarigu aŭ forigu la adresadon ĉe malmuntado, kaj faru la samon denove post rekonekto. Valoroj el unu sukcesa sesio ne devas esti malmolaj, ĉar la servilo povas doni malsaman paron sekvan fojon.
La mediovariabloj kiujn la kliento eksportas estas la sola subtenata enigo por tiu laboro.
env | grep -E '^ifconfig_|^route_'Ene de route-up-skripto tiuj variabloj estas haveblaj; el cron-laboro aŭ permana ŝelo ili ne estas. Konfirmu kiun vivciklan hokon via versio uzas, kaj konfirmu ke la hoko ruliĝas kun sufiĉa privilegio por ŝanĝi la interfacon, ĉar la kliento eble jam falis al senprivilegia uzanto.
Testu la tutan vivciklon, ne unu sesion
Levigu la tunelon, kontrolu la adreson sur la aparato, tiam rekonektu kaj kontrolu ĝin denove. Agordo kiu funkcias unufoje kaj malsukcesas je la dua provo kutime signifas ke la delegita paŝo ruliĝas nur je la unua konekto.
Poste testu ambaŭ akceptkriteriojn kune: freŝa SSH-konekto tra la intencita administra vojo funkcias, kaj permesita aplikaĵo uzas la tunelon ĝuste.
Malnova SSH-sesio kiu hazarde pluvivas dum la tunelo havas neniun adreson ne estas sukceso, kaj ĝi estas ekzakte la stato kiun ĉi tiu agordo produktas kiam neniu transprenas la laboron. Kontrolu unue la interfacan adreson, poste la administran respondan vojon, poste la aplikaĵon. Se du el la tri estas malĝustaj, la agordo movis laboron sen doni al ĝi posedanton.