SSH-bastion of directe VPN-toegang: welk beleid geldt?

Of VPN-gebruikers servers kunnen bereiken zonder een spronghost te passeren, is een beleidsvraag in netwerkkleding. Als het bastion een vereiste controle uitvoert, moet deelnemen aan de VPN daarheen leiden en niet eromheen. Als de spronghost alleen een segment overbrugde dat voorheen onbereikbaar was, kan een smal direct pad de eerlijke vervanging zijn. Werk de onderstaande controles in volgorde af en stop bij de eerste die faalt, want dat antwoord bepaalt de rest.

Controleer wat het bastion werkelijk beheert

Begin met bewijs over het heden, niet met een diagram uit het ontwerpdocument. Kijk naar de SSH-configuratie en het packetfilter van het doel: als inkomende poort 22 alleen van het adres van het bastion wordt aanvaard, is de spronghost een afgedwongen controle. Als dezelfde poort verbindingen van de hele VPN-pool aanvaardt, was het bastion een gemak en woont de handhaving heel ergens anders. De ticketgeschiedenis bevestigt meestal welke van de twee het eerst bestond.

Formuleer de bevinding in één zin die de controle noemt die het bastion levert: bestemmingsbeperking, een tweede authenticatiestap, sessie-opname of operationele zichtbaarheid tijdens een incident. Die zin is wat het vervangingsbeleid moet behouden.

Controleer of het doel de paden kan onderscheiden

Regels voor bronadressen werken alleen zolang de twee paden met verschillende bronadressen aankomen. Een VPN-gateway die verkeer naar het serversubnet maskeert, wist dat verschil uit, en dan lijkt elke verbinding naar poort 22 van de gateway te komen. De controle is lokaal op het doel en duurt een moment: som de opgezette SSH-sessies op en lees voor elk daarvan het peeradres.

Wanneer beide paden tot één adres samenvallen, moet het onderscheid eerder worden gemaakt, door welke bestemmingen de VPN mag pushen en door de eigen filters van de gateway. Een regel op het doel toevoegen creëert in die situatie de illusie van een grens zonder te veranderen wat aankomt.

Controleer wat elk record werkelijk bevat

Drie verschillende logboeken beschrijven drie verschillende gebeurtenissen, en geen ervan vervangt een ander. Het verbindingsrecord van de VPN toont dat een identiteit het netwerkbereik binnenging. Het doorstuurrecord van het bastion toont een TCP-kanaal dat het verlaat richting een bestemming en poort. Het authenticatielogboek van het doel toont dat een account zich via SSH aanmeldde. Juist het samen lezen levert een tijdlijn op; één alleen lezen levert een gok op.

Geen van die records bevat wat er binnen de versleutelde sessie tussen client en doel gebeurde. Als beoordeling op opdrachtniveau een vereiste is, heeft die een bewust ingezet opnamemechanisme nodig met eigen regels voor gegevensverwerking. Dat van de logboeken van de spronghost verwachten is de manier waarop een auditgat verborgen blijft tot het ertoe doet.

Controleer waar het beleid werkelijk wordt afgedwongen

Een clientinstelling zoals ProxyJump is een verzoek, geen beperking. OpenSSH opent graag een directe verbinding wanneer het doel bereikbaar is, dus configuratiebestanden op laptops beschrijven de bedoeling terwijl firewalls de uitkomst bepalen. Handhaving hoort bij de toegestane bestemmingen van de VPN-gateway en bij de eigen toegangsregels van het doel, en geen van beide kan de gebruiker aanpassen. Controleer tegelijk de alternatieve paden: een tweede interface, een openbare listener, een mesh-laag of een oudere site-naar-site-tunnel kunnen elk de sluiproute herstellen die je net hebt gesloten.

Configureer ProxyJump toch, want het maakt de goedgekeurde route de makkelijke en voorkomt dat routinewerk uitzonderingen oplevert. Bevestig wat de client werkelijk oplost voordat je erop vertrouwt.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

Verifieer met een bewuste directe poging

Beleid dat nooit is getest, is een hoop. Probeer vanaf een client die aan de VPN hangt het pad dat nu geweigerd zou moeten worden, probeer daarna het goedgekeurde, en bewaar beide resultaten. De geweigerde poging is het bewijs dat de wijziging effect had.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

Een schoon resultaat ziet eruit als een geweigerde of verlopen directe verbinding naar het doeladres, gevolgd door een geslaagde aanmelding op de spronghost en een authenticatievermelding aan de doelzijde die de ondersteunde bron noemt. Alles anders betekent dat de grens nog poreus is, wat de documentatie ook zegt. Noteer de datum, de gewijzigde regel en de twee uitkomsten, en geef het herstelpad een eigenaar en een vervaldatum zodat noodtoegang niet stilletjes de dagelijkse route wordt.