ifconfig-noexec reddar ikkje SSH-økta di: kva det faktisk gjer

I ein forumtråd, ifconfig-noexec blir det tilbode som løysinga som held ei SSH-økt i live når ein tunnel kjem opp. Resonnementet høyrest rimeleg ut til du sjekkar kva valet faktisk rører. Det hindrar OpenVPN i å konfigurere adressa til tunnelgrensesnittet og gir i staden verdiane til skript; det seier ingenting om kvar svara på administrasjonstilkoplinga di går. Å tru det motsette gir ein tunnel utan brukbar adresse og ei SSH-økt som framleis døyr.

Kva valet faktisk delegerer

Som standard set klienten opp tunnel-eininga og tildeler den lokale og den eksterne adressa serveren gav han. Med ifconfig-noexec sett blir det trinnet hoppa over, og dei forhandla verdiane blir eksporterte til skriptmiljøet slik at noko anna kan bruke dei.

Eigarskapet flyttar seg. Ingenting blir funne opp på plassen.

Så spørsmålet valet svarer på, er kven som konfigurerer grensesnittet, og spørsmålet det ikkje svarer på, er korleis pakkar finn vegen tilbake til deg. Hald dei to frå kvarandre, elles brukar du ein heil kveld på å redigere ruter for å kompensere for eit grensesnitt utan adresse.

Tre like val med ulike arbeidsoppgåver

Familien er lett å forveksle fordi namna skil seg med eitt ord og symptoma overlappar. Les kva kvart av dei undertrykkjer før du vel noko.

Dette er alternativ som må forståast kvar for seg, ikkje eit sett som blir limt saman. Å undertrykkje adressekonfigurasjon undertrykkjer ikkje ruteendringar, brannmurreglar eller dei pusja vala som ber DNS. Eit delegert skript står også fritt til å endre ruter, og det er ei avgjerd du overlèt i staden for å unngå.

Viss ein leverandørklient pakkar inn motoren, bruk den støtta integrasjonen i staden for å sleppe eit direktiv på lågt nivå inn i ein profil og håpe at innpakninga respekterer det. Innpakningar regenererer ofte profilen ved tilkopling, så ei manuell endring forsvinn utan feil. Sjekk kvar klienten oppbevarer innstillingane før du brukar ein heil kveld på fila. Det gjeld kvar rad i tabellen, ikkje berre den du kom for.

SSH-økta du meinte å verne

Ei SSH-tilkopling har ei kjeldeadresse, ei måladresse og ein svarveg. På ein server som nettopp har installert standard full tunnel, passar svaret til den offentlege adressa di med tunnelen, og VPN-gatewayen slepper det.

Ingenting i adressekonfigurasjonen til tunnelgrensesnittet endrar det.

Det som fiksar det, er ei meir spesifikk rute for administrasjonsadressa di gjennom gatewayen før tunnelen, eller ein policyregel som styrer den trafikken, pluss filterinnstillingane verten din brukar. Dei to problema dukkar nokre gonger opp saman, og slik blir det eine forveksla med kuren for det andre. Test dei kvar for seg: set opp tunnelen utan valet, sjå på grensesnittadressa og svarvegen, og avgjer deretter kva av dei to som faktisk er øydelagd.

Kva eit delegert skript må ta over

Viss du verkeleg vil at ein annan eigar skal konfigurere grensesnittet, list opp arbeidet: bruk den lokale og den eksterne adressa, set opp eininga, gjenopprett eller fjern adresseringa ved nedkopling, og gjer det same igjen etter ei ny tilkopling. Verdiar frå éi vellukka økt må ikkje hardkodast, fordi serveren kan gi eit anna par neste gong.

Miljøvariablane klienten eksporterer, er det einaste støtta inndata for det arbeidet.

env | grep -E '^ifconfig_|^route_'

Innanfor eit route-up skript er dei variablane tilgjengelege; frå ein cron-jobb eller eit manuelt skal er dei ikkje. Stadfest kva livssykluskrok versjonen din brukar, og stadfest at kroken køyrer med nok rettar til å endre grensesnittet, sidan klienten kan allereie ha gått ned til ein uprivilegert brukar.

Test heile livssyklusen, ikkje éi økt

Set opp tunnelen, sjekk adressa på eininga, kople deretter til på nytt og sjekk igjen. Ein konfigurasjon som verkar éin gong og feilar på andre forsøk betyr vanlegvis at det delegerte trinnet berre køyrer ved den første tilkoplinga.

Test så begge akseptkriteria saman: ei ny SSH-tilkopling gjennom den tiltenkte administrasjonsvegen verkar, og ein tillaten applikasjon brukar tunnelen rett.

Ei gammal SSH-økt som tilfeldigvis overlever medan tunnelen ikkje har adresse, er ikkje ein suksess, og det er nøyaktig tilstanden dette valet lagar når ingen tar over arbeidet. Sjekk grensesnittadressa først, deretter svarvegen til administrasjonen, deretter applikasjonen. Viss to av tre er gale, flytta valet arbeid utan å gi det ein eigar.