Behåll lokal SSH när värden kör en utgående VPN

En liten Linux-server kör en utgående VPN för programmet den hostar, och administratören vill fortfarande nå den via SSH från skrivbordet intill. Det är ett rimligt krav, och det kräver vanligtvis varken portvidarebefordran, en leverantörsadress eller ett hål i tunneln. Det som behövs är en administrationsväg som är designad med avsikt i stället för ärvd från vad VPN-klienten gjorde med routingtabellen.

Stegen nedan förutsätter att administratören är på samma LAN.Fjärradministration är ett annat problem med ett annat svar.

Bind SSH till adressen som administratörerna använder

Börja vid lyssnaren.ss -ltnp | grep :22 visar vad sshd är bundet till, och en lyssnare på 0.0.0.0 tar emot anslutningar från varje gränssnitt, inklusive tunneln. Att binda till LAN-adressen är snävare och gör avsikten synlig:ListenAddress 192.168.10.20 i sshd_config, följt av ett konfigurationstest och en omladdning. Ett stavfel i den adressen är mer synligt än ett jokertecken, eftersom sshd vägrar starta när adressen inte finns.

Behåll värdnyckelkontrollen och autentiseringen per användare precis som de är. ”Det är bara det lokala nätet” är inte en autentiseringsmetod, och en administrationskanal som hoppar över nyckelverifieringen eftersom rutten är kort är en administrationskanal som väntar på missbruk. En DHCP-reservation eller en statisk adress gör målet förutsägbart utan att göra det till serverns offentliga identitet.

Håll LAN-rutten utanför tunneln

En värd med en adress på 192.168.10.0/24 har en ansluten rutt för det prefixet, och en mer specifik rutt slår VPN:ens standardrutt i samma tabell. Det är därför lokal SSH ofta fortsätter att fungera av sig själv när tunneln kommer upp. Verifiera det i stället för att anta:ip route get 192.168.10.50 namnger gränssnittet och källadressen som kärnan skulle använda, och svaret borde vara LAN-enheten, inte tunneln. Upprepa kontrollen från administratörens maskin också, eftersom dess egen tabell avgör om paketen ens kommer fram. Två värdar på samma kabel kan vara oense om vilken riktning som är nåbar.

Antagandet brister på två ställen. En policy-baserad routingregel kan skicka trafik till en tabell vars standard pekar in i tunneln innan huvudtabellen konsulteras. En VPN-klient med lås- eller kill switch-funktion kan också blockera trafik som inte går in i tunneln, oavsett vad routingtabellen säger.

Routade administrations-VLAN är det andra fallet. Om administratören sitter på 192.168.50.0/24 bakom den lokala routern behöver servern en explicit rutt för det prefixet via 192.168.10.1, och den rutten måste överleva en återanslutning. Håll undantaget specifikt för administrationsprefixet; ett brett undantag för privata intervall underminerar tunnelns syfte.

Gör brandväggsundantaget lika smalt som regeln

Om värden kör en brandvägg ska du bara tillåta SSH från administrationskällan och bara på LAN-gränssnittet. En regel som tillåter port 22 från överallt är bredare än kravet och svårare att försvara i en granskning. På en nftables-värd hör regeln hemma i input-kedjan med gränssnitt och källa matchade; på en iptables-värd är motsvarigheten ett par matchningar på -i och -s. Kommentera regeln med den administratörsgrupp den tjänar, så nästa revision inte behöver gissa varför port 22 är öppen.

Kontrollera också VPN-klientens eget filter. Vissa klienter installerar regler som släpper lokal trafik av design, och en korrekt brandväggsregel ovanpå ett drop på klientnivå ändrar ingenting. Läs klientens konfiguration innan du redigerar värdens brandvägg, eftersom två filter i serie ger ett fel som inte liknar något av dem.

Testa båda tillstånden

Kör testet två gånger: en gång med tunneln ansluten och en gång frånkopplad. Bekräfta i varje tillstånd lyssnaren, rutten och en faktisk SSH-inloggning från administratörens maskin. En väg som bara fungerar medan tunneln är uppe är inte en lokal administrationsväg; det är en tillfällighet.

Starta sedan om tunneln medan en SSH-session är öppen. En session som överlever bevisar att routingen är stabil; en session som faller säger dig att klienten skriver om rutter eller filter vid återanslutning, vilket är värt att veta före en incident i stället för under en.

Anteckna källadressen du testade från, eftersom en regel skriven för 192.168.10.50 misslyckas tyst när administratörens bärbara dator flyttar till ett annat subnät.

Skriv återställningsvägen i runbooken

Bestäm nu vad som händer om den utgående VPN:en bryter den lokala vägen. Konsolåtkomst, en andra administrationsadress eller en dokumenterad procedur för att stoppa klienten är alla legitima svar, och vilket som helst av dem är bättre än att upptäcka problemet i stunden du måste logga in. Om servern är fjärransluten finns inte den lokala vägen, och rätt design är en separat godkänd fjärråtkomstväg eller en bastion i stället för en exponerad publik port.

Håll de två rollerna åtskilda i dokumentationen: lokal SSH för administratören som är i närheten, och den utgående tunneln för programmets trafik. När de rollerna är nedskrivna har en framtida ändring i någon av dem en uppenbar plats att kontrolleras, och nästa person behöver inte återupptäcka varför en server med en VPN fortfarande svarar på sin LAN-adress.