ifconfig-noexec redt je SSH-sessie niet: wat het echt doet

In een forumthread, ifconfig-noexec wordt het aangeboden als de oplossing die een SSH-sessie in leven houdt wanneer er een tunnel omhoogkomt. De redenering klinkt aannemelijk tot je kijkt wat de optie werkelijk raakt. Het weerhoudt OpenVPN ervan het adres van de tunnelinterface te configureren en geeft die waarden in plaats daarvan aan scripts; over waar de antwoorden op je beheerverbinding heen gaan, zegt het niets. Het tegenovergestelde geloven levert een tunnel zonder bruikbaar adres op en een SSH-sessie die alsnog sterft.

Wat de optie werkelijk delegeert

Standaard brengt de client het tunnelapparaat omhoog en wijst het de lokale en externe adressen toe die de server hem gaf. Met ifconfig-noexec ingesteld wordt die stap overgeslagen, en de onderhandelde waarden worden naar de scriptomgeving geëxporteerd zodat iets anders ze kan toepassen.

Het eigendom verschuift. Er wordt niets uitgevonden in de plaats.

De vraag die de optie dus beantwoordt, is wie de interface configureert, en de vraag die zij niet beantwoordt, is hoe pakketten de weg terug naar jou vinden. Houd die twee gescheiden, anders besteed je een hele avond aan het bewerken van routes om een interface zonder adres te compenseren.

Drie vergelijkbare opties met verschillende taken

De familie is makkelijk te verwarren omdat de namen één woord verschillen en de symptomen overlappen. Lees wat elk onderdrukt voordat je er een kiest.

Dit zijn alternatieven om afzonderlijk te begrijpen, geen set om samen te plakken. Het onderdrukken van adresconfiguratie onderdrukt geen routewijzigingen, firewallregels of de gepushte opties die DNS vervoeren. Een gedelegeerd script mag ook routes wijzigen, en dat is een beslissing die je overdraagt in plaats van vermijdt.

Als een leveranciersclient de engine omhult, gebruik dan de ondersteunde integratie in plaats van een richtlijn op laag niveau in een profiel te stoppen en te hopen dat de wrapper die respecteert. Wrappers regenereren het profiel vaak bij het verbinden, zodat een handmatige wijziging zonder fout verdwijnt. Controleer waar de client zijn instellingen bewaart voordat je een hele avond aan het bestand besteedt. Dat geldt voor elke rij in de tabel, niet alleen voor de rij waarvoor je kwam.

De SSH-sessie die je wilde beschermen

Een SSH-verbinding heeft een bronadres, een bestemmingsadres en een antwoordpad. Op een server die net een volledige-tunnelstandaard heeft geïnstalleerd, past het antwoord op je publieke adres bij de tunnel, en de VPN-gateway gooit het weg.

Niets in de adresconfiguratie van de tunnelinterface verandert dat.

Wat het oplost, is een specifiekere route voor je beheeradres via de gateway vóór de tunnel, of een beleidsregel die dat verkeer stuurt, plus de filterinstellingen die je host toepast. De twee problemen verschijnen soms samen, en zo wordt het ene aangezien voor de kuur van het andere. Test ze apart: breng de tunnel omhoog zonder de optie, kijk naar het interfaceadres en het antwoordpad en beslis dan welke van de twee echt stuk is.

Wat een gedelegeerd script moet overnemen

Als je echt wilt dat een andere eigenaar de interface configureert, som het werk op: pas het lokale en het externe adres toe, breng het apparaat omhoog, herstel of verwijder de adressering bij het afbreken, en doe hetzelfde opnieuw na een herverbinding. Waarden van één geslaagde sessie mogen niet hardgecodeerd worden, omdat de server de volgende keer een ander paar kan geven.

De omgevingsvariabelen die de client exporteert, zijn de enige ondersteunde invoer voor dat werk.

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

Binnen een route-up script zijn die variabelen beschikbaar; vanuit een cronjob of een handmatige shell niet. Bevestig welke levenscyclus-hook je versie gebruikt, en bevestig dat de hook met voldoende rechten draait om de interface te wijzigen, want de client is mogelijk al teruggevallen op een niet-geprivilegieerde gebruiker.

Test de hele levenscyclus, niet één sessie

Breng de tunnel omhoog, controleer het adres op het apparaat, verbind dan opnieuw en controleer het weer. Een configuratie die één keer werkt en bij de tweede poging faalt, betekent meestal dat de gedelegeerde stap alleen bij de eerste verbinding draait.

Test dan beide acceptatiecriteria samen: een nieuwe SSH-verbinding via het bedoelde beheerpad werkt, en een toegestane toepassing gebruikt de tunnel correct.

Een oude SSH-sessie die toevallig overleeft terwijl de tunnel geen adres heeft, is geen succes, en het is precies de toestand die deze optie oplevert wanneer niemand het werk overneemt. Controleer eerst het interfaceadres, dan het antwoordpad van het beheer, dan de toepassing. Als twee van de drie fout zijn, heeft de optie werk verplaatst zonder er een eigenaar aan te geven.