SSH på en andra privat väg medan VPN:en är igång

En maskin når en annan via en VPN, och nu vill någon ha samma skal över ett leverantörs privata nätverk. Vägen finns, ping lyckas och SSH vägrar ändå. Den vanliga orsaken är att demonen aldrig lyssnade på den nya adressen, så det finns inget att ansluta till. Det här är ett adressbindningsproblem innan det är ett brandväggsproblem.

Varför en ny väg inte skapar en ny lyssnare

En lyssnande socket skapas av en process som namnger de adresser den tar emot på. En väg talar bara om för paketen vart de ska; den skapar ingen lyssnare på destinationen. När sshd är konfigurerad med en enda ListenAddress avvisas anslutningar till alla andra lokala adresser även om gränssnittet är uppe. Samma sak gäller en socket-enhet som äger porten, vilket är varför den första kontrollen alltid är vad som faktiskt lyssnar.

Jämför de två vägarna efter destinationsadress, inte efter gränssnittsnamn. En klient ansluter till en adress, och den adressen måste vara bunden innan någon brandväggsregel spelar roll.

Lista adresserna och lyssnarna

Innan du ändrar något, registrera adresserna på värden och de sockets som finns nu.

ip -br addr
ss -ltnp | grep ':22'

Adresslistan visar vilken privat adress som är verklig och på vilket gränssnitt, medan socketlistan visar om något är bundet till den. En lyssnare på 0.0.0.0:22 accepterar redan varje adress, så en ny bindning lägger inte till något. En lyssnare på en specifik adress förklarar avvisandet direkt. Om porten tillhör en socket-enhet i stället för demonen är demonkonfigurationen inte hela historien.

Lägg till bindningen och behåll den gamla

OpenSSH accepterar flera ListenAddress-poster, så VPN-vägen kan finnas kvar medan den privata läggs till. Testa filen innan du laddar om den.

sshd -t
systemctl reload sshd

Ett misslyckat konfigurationstest lämnar den körande demonen orörd, och det är precis vad du vill medan du är ansluten via vägen du redigerar. Behåll den befintliga posten, lägg till den nya lokala adressen och bekräfta att tjänsten laddas om utan att den aktuella sessionen tappas. På socket-aktiverade installationer lägger du till adressen i socket-enheten i stället och laddar om den enheten. Läs sedan lyssnarlistan igen, eftersom en bindning som aldrig dök upp betyder att fel komponent redigerades.

Verifiera den nya sessionen innan du stänger den gamla

Anslut till den nya adressen medan den ursprungliga sessionen fortfarande är öppen, och använd utförlig utdata för att se vilken adress och nyckel som användes. Håll den ursprungliga sessionen öppen tills testet lyckas två gånger.

ssh -v [email protected]

Läs felsökningsraderna för destinationsadressen och den presenterade värdnyckeln. Bekräfta värdnyckelns fingeravtryck mot ett värde du redan litar på, i stället för att acceptera en okänd nyckel eftersom nätverket beskrivs som privat. Den nya destinationen behöver en egen known_hosts-post, och det är väntat. Den gamla administrationssessionen bör stängas först när den privata vägen fungerar.

SSH skyddar transporten, men det gör inte två nätverk likvärdiga i sig. Bestäm om förtroendet för den privata överföringen passar data innan du förlitar dig på den.