ifconfig-noexec redder ikke din SSH-session: hvad den gør
Den undertrykker OpenVPNs egen opsætning af grænsefladeadressen. Den reserverer ikke en SSH-svarroute, slår ikke alle ruteændringer fra og leverer ikke den manglende adresse.
Et sted i en forumtråd tilbydes ifconfig-noexec som rettelsen, der holder en SSH-session i live, når en tunnel kommer op. Ræsonnementet lyder plausibelt, indtil man undersøger, hvad indstillingen rører. Den forhindrer OpenVPN i at konfigurere tunnelgrænsefladens adresse og giver i stedet værdierne til scripts; om hvor svar på din administrationsforbindelse går hen, siger den intet. Tror man andet, får man en tunnel uden brugbar adresse og en SSH-session, der stadig dør.
Hvad indstillingen faktisk delegerer
Som standard rejser klienten tunnel-enheden og tildeler den lokale og fjernadresse, som serveren gav den. Med ifconfig-noexec sat springes dette trin over, og de forhandlede værdier eksporteres til scriptmiljøet, så noget andet kan anvende dem.
Ejerskabet flytter. Intet opfindes i stedet.
Spørgsmålet, indstillingen besvarer, er altså hvem der konfigurerer grænsefladen, og det spørgsmål, den ikke besvarer, er hvordan pakker finder vejen tilbage til dig. Hold dem adskilt, ellers bruger du en aften på at redigere ruter for at kompensere for en grænseflade uden adresse.
Tre lignende indstillinger med forskellige opgaver
Familien er let at forveksle, fordi navnene adskiller sig med ét ord, og symptomerne overlapper. Læs, hvad hver enkelt undertrykker, før du vælger nogen af dem.
| Indstilling | Hvad der holder op med at ske |
|---|---|
ifconfig-noexec | OpenVPNs egen tunneladresse-konfiguration; værdierne går i stedet til scripts |
route-noexec | Automatisk tilføjelse og fjernelse af ruter; rutedetaljer går til et script |
route-nopull | Ruter, serveren skubber, og relaterede indstillinger som DNS afvises |
Det er alternativer, man skal forstå enkeltvis, ikke et sæt, man klistrer sammen. At undertrykke adressekonfiguration undertrykker ikke ruteændringer, firewallregler eller de skubbede indstillinger, der bærer DNS. Et delegeret script er også frit til at ændre ruter, og det er en beslutning, du overlader frem for at undgå.
Hvis en leverandørklient indpakker motoren, brug dens understøttede integration i stedet for at smide en direktiv på lavt niveau i en profil og håbe, at indpakningen respekterer den. Indpakninger gendanner ofte profilen ved forbindelse, så en manuel ændring forsvinder uden en fejl. Kontroller, hvor klienten gemmer sine indstillinger, før du bruger en aften på filen. Det gælder hver række i tabellen, ikke kun den, du kom for.
Den SSH-session, du ville beskytte
En SSH-forbindelse har en kildeadresse, en destinationsadresse og en svarrute. På en server, der netop har installeret en fuldtunnel-standard, matcher svaret på din offentlige adresse tunnelen, og VPN-gatewayen dropper det.
Intet i tunnelgrænsefladens adressekonfiguration ændrer det.
Det, der retter det, er en mere specifik rute for din administrationsadresse gennem gatewayen før tunnelen, eller en politikregel, der styrer den trafik, plus de filterindstillinger, din vært anvender. De to problemer optræder undertiden sammen, og sådan forveksles det ene med en kur for det andet. Test dem hver for sig: rejs tunnelen uden indstillingen, se på grænsefladens adresse og svarruten, og afgør så, hvilken af de to der faktisk er brudt.
Hvad et delegeret script skal overtage
Hvis du virkelig vil have en anden ejer til at konfigurere grænsefladen, så opregn arbejdet: anvend lokal- og fjernadressen, rejs enheden, gendan eller fjern adresseringen ved nedrivning, og gør det samme igen efter en genforbindelse. Værdier fra én vellykket session må ikke hardcodes, fordi serveren kan give et andet par næste gang.
De miljøvariabler, klienten eksporterer, er det eneste understøttede input til dette arbejde.
env | grep -E '^ifconfig_|^route_'Inde i et route-up-script er disse variabler tilgængelige; fra et cron-job eller en manuel shell er de ikke. Bekræft, hvilket livscyklus-hook din version bruger, og bekræft, at hooket kører med nok privilegier til at ændre grænsefladen, da klienten måske allerede er skiftet til en uprivilegeret bruger.
Test hele livscyklussen, ikke én session
Rejs tunnelen, kontroller adressen på enheden, genopret forbindelsen og kontroller den igen. En konfiguration, der virker én gang og fejler ved andet forsøg, betyder normalt, at det delegerede trin kun kører ved første forbindelse.
Test derefter begge acceptkriterier sammen: en ny SSH-forbindelse gennem den tilsigtede administrationsvej virker, og en tilladt applikation bruger tunnelen korrekt.
En gammel SSH-session, der tilfældigvis overlever, mens tunnelen ikke har nogen adresse, er ikke en succes, og det er præcis den tilstand, indstillingen frembringer, når ingen overtager arbejdet. Kontroller grænsefladens adresse først, derefter administrationssvarruten, derefter applikationen. Hvis to af de tre er forkerte, har indstillingen flyttet arbejde uden at give det en ejer.