ifconfig-noexec räddar inte din SSH-session: vad det faktiskt gör
Det undertrycker OpenVPN:s egen adresskonfiguration för gränssnittet. Det reserverar ingen svarsväg för SSH, stänger inte av alla ruttändringar och levererar inte den saknade adressen.
I en forumtråd ifconfig-noexec erbjuds det som rättningen som håller en SSH-session vid liv när en tunnel kommer upp. Resonemanget låter rimligt tills du kontrollerar vad valet faktiskt rör vid. Det hindrar OpenVPN från att konfigurera tunnelgränssnittets adress och lämnar i stället värdena till skript; om vart svaren på din hanteringsanslutning tar vägen säger det ingenting. Att tro motsatsen ger en tunnel utan användbar adress och en SSH-session som ändå dör.
Vad valet faktiskt delegerar
Som standard tar klienten upp tunnel-enheten och tilldelar de lokala och avlägsna adresser som servern gav den. Med ifconfig-noexec satt hoppas det steget över, och de förhandlade värdena exporteras till skriptmiljön så att något annat kan tillämpa dem.
Ägandet flyttas. Ingenting hittas på i dess ställe.
Frågan valet svarar på är alltså vem som konfigurerar gränssnittet, och frågan det inte svarar på är hur paket hittar vägen tillbaka till dig. Håll de två åtskilda, annars spenderar du en hel kväll på att redigera rutter för att kompensera ett gränssnitt utan adress.
Tre liknande val med olika uppgifter
Familjen är lätt att förväxla eftersom namnen skiljer sig på ett ord och symtomen överlappar. Läs vad var och en undertrycker innan du väljer någon.
| 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 |
Det här är alternativ att förstå var för sig, inte en uppsättning att klistra ihop. Att undertrycka adresskonfiguration undertrycker inte ruttändringar, brandväggsregler eller de pushade val som bär DNS. Ett delegerat skript får också ändra rutter, och det är ett beslut du lämnar över i stället för att undvika.
Om en leverantörsklient omsluter motorn, använd dess stödda integration i stället för att slänga in ett lågnivådirektiv i en profil och hoppas att omslaget respekterar det. Omslag regenererar ofta profilen vid anslutning, så en manuell ändring försvinner utan fel. Kontrollera var klienten håller sina inställningar innan du lägger en hel kväll på filen. Det gäller varje rad i tabellen, inte bara den du kom för.
SSH-sessionen du menade att skydda
En SSH-anslutning har en källadress, en måladress och en svarsväg. På en server som just installerat standard för full tunnel matchar svaret till din publika adress tunneln, och VPN-gatewayen kastar det.
Ingenting i adresskonfigurationen för tunnelgränssnittet ändrar det.
Det som löser det är en mer specifik rutt för din hanteringsadress via gatewayen före tunneln, eller en policyregel som styr den trafiken, plus de filterinställningar som din värd tillämpar. De två problemen dyker ibland upp tillsammans, och så tas det ena för att bota det andra. Testa dem separat: ta upp tunneln utan valet, titta på gränssnittsadressen och svarsvägen och avgör sedan vilken av de två som faktiskt är trasig.
Vad ett delegerat skript måste ta över
Om du verkligen vill att en annan ägare konfigurerar gränssnittet, räkna upp arbetet: tillämpa den lokala och den avlägsna adressen, ta upp enheten, återställ eller ta bort adresseringen vid nedkoppling och gör samma sak igen efter en återanslutning. Värden från en lyckad session får inte hårdkodas, eftersom servern kan ge ett annat par nästa gång.
De miljövariabler som klienten exporterar är den enda stödda indatan för det arbetet.
env | grep -E '^ifconfig_|^route_'Inom ett route-up skript är de variablerna tillgängliga; från ett cronjobb eller ett manuellt skal är de inte det. Bekräfta vilken livscykelkrok din version använder, och bekräfta att kroken körs med tillräckliga rättigheter för att ändra gränssnittet, eftersom klienten kan redan ha gått ned till en oprivilegierad användare.
Testa hela livscykeln, inte en enda session
Ta upp tunneln, kontrollera adressen på enheten, anslut sedan igen och kontrollera den på nytt. En konfiguration som fungerar en gång och misslyckas på andra försöket betyder vanligtvis att det delegerade steget bara körs vid den första anslutningen.
Testa sedan båda acceptanskriterierna tillsammans: en ny SSH-anslutning via den avsedda hanteringsvägen fungerar, och ett tillåtet program använder tunneln korrekt.
En gammal SSH-session som råkar överleva medan tunneln saknar adress är ingen framgång, och det är exakt det tillstånd detta val skapar när ingen tar över arbetet. Kontrollera gränssnittsadressen först, sedan hanteringens svarsväg, sedan programmet. Om två av tre är fel har valet flyttat arbete utan att ge det en ägare.