ifconfig-noexec redder ikke SSH-økten din: hva det faktisk gjør

I en forumtråd, ifconfig-noexec blir det tilbudt som løsningen som holder en SSH-økt i live når en tunnel kommer opp. Resonnementet høres rimelig ut til du sjekker hva valget faktisk berører. Det hindrer OpenVPN i å konfigurere adressen til tunnelgrensesnittet og gir i stedet verdiene til skript; det sier ingenting om hvor svarene på administrasjonstilkoblingen din går. Å tro det motsatte gir en tunnel uten brukbar adresse og en SSH-økt som fortsatt dør.

Hva valget faktisk delegerer

Som standard setter klienten opp tunnel-enheten og tildeler den lokale og den eksterne adressen serveren ga den. Med ifconfig-noexec satt hoppes det trinnet over, og de forhandlede verdiene eksporteres til skriptmiljøet slik at noe annet kan bruke dem.

Eierskapet flyttes. Ingenting blir funnet opp på plassen.

Så spørsmålet valget svarer på, er hvem som konfigurerer grensesnittet, og spørsmålet det ikke svarer på, er hvordan pakker finner veien tilbake til deg. Hold de to fra hverandre, ellers bruker du en hel kveld på å redigere ruter for å kompensere for et grensesnitt uten adresse.

Tre like valg med ulike jobber

Familien er lett å forveksle fordi navnene skiller seg med ett ord og symptomene overlapper. Les hva hvert av dem undertrykker før du velger noe.

Dette er alternativer som må forstås hver for seg, ikke et sett som limes sammen. Å undertrykke adressekonfigurasjon undertrykker ikke ruteendringer, brannmurregler eller de pushede valgene som bærer DNS. Et delegert skript står også fritt til å endre ruter, og det er en beslutning du overlater i stedet for å unngå.

Hvis en leverandørklient pakker inn motoren, bruk den støttede integrasjonen i stedet for å slippe en direktiv på lavt nivå inn i en profil og håpe at innpakningen respekterer den. Innpakninger regenererer ofte profilen ved tilkobling, så en manuell endring forsvinner uten feil. Sjekk hvor klienten oppbevarer innstillingene før du bruker en hel kveld på filen. Det gjelder hver rad i tabellen, ikke bare den du kom for.

SSH-økten du mente å beskytte

En SSH-tilkobling har en kildeadresse, en måladresse og en svarvei. På en server som nettopp har installert standard full tunnel, passer svaret til din offentlige adresse med tunnelen, og VPN-gatewayen slipper det.

Ingenting i adressekonfigurasjonen til tunnelgrensesnittet endrer det.

Det som fikser det, er en mer spesifikk rute for administrasjonsadressen din gjennom gatewayen før tunnelen, eller en policyregel som styrer den trafikken, pluss filterinnstillingene verten din bruker. De to problemene dukker noen ganger opp sammen, og slik blir det ene forvekslet med kuren for det andre. Test dem hver for seg: sett opp tunnelen uten valget, se på grensesnittadressen og svarveien, og avgjør deretter hvilken av de to som faktisk er ødelagt.

Hva et delegert skript må ta over

Hvis du virkelig vil at en annen eier skal konfigurere grensesnittet, list opp arbeidet: bruk den lokale og den eksterne adressen, sett opp enheten, gjenopprett eller fjern adresseringen ved nedkobling, og gjør det samme igjen etter en ny tilkobling. Verdier fra én vellykket økt må ikke hardkodes, fordi serveren kan gi et annet par neste gang.

Miljøvariablene klienten eksporterer, er det eneste støttede inndata for det arbeidet.

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

Innenfor et route-up skript er de variablene tilgjengelige; fra en cron-jobb eller et manuelt skall er de ikke. Bekreft hvilken livssykluskrok versjonen din bruker, og bekreft at kroken kjører med nok rettigheter til å endre grensesnittet, siden klienten kan allerede ha gått ned til en uprivilegert bruker.

Test hele livssyklusen, ikke én økt

Sett opp tunnelen, sjekk adressen på enheten, koble deretter til på nytt og sjekk igjen. En konfigurasjon som virker én gang og feiler på andre forsøk betyr vanligvis at det delegerte trinnet bare kjører ved den første tilkoblingen.

Test så begge akseptkriteriene sammen: en ny SSH-tilkobling gjennom den tiltenkte administrasjonsveien virker, og en tillatt applikasjon bruker tunnelen riktig.

En gammel SSH-økt som tilfeldigvis overlever mens tunnelen ikke har adresse, er ikke en suksess, og det er nøyaktig tilstanden dette valget lager når ingen tar over arbeidet. Sjekk grensesnittadressen først, deretter administrasjonens svarvei, deretter applikasjonen. Hvis to av tre er gale, flyttet valget arbeid uten å gi det en eier.