SSH på en andre privat vei mens VPN-en fortsatt er oppe

Én maskin når en annen over en VPN, og noen vil nå ha samme skall over et privat nettverk hos leverandøren. Ruten finnes, ping lykkes, og SSH nekter fortsatt. Den vanlige årsaken er at daemonen aldri lyttet på den nye adressen, så det er ingenting å koble til. Dette er et adressebindingsproblem før det er et brannmurproblem.

Hvorfor en ny rute ikke lager en ny lytter

En lyttende socket opprettes av en prosess som navngir adressene den vil godta. En rute forteller bare pakkene hvor de skal reise; den lager ikke en lytter på destinasjonen. Når sshd er konfigurert med én ListenAddress, avvises tilkoblinger til enhver annen lokal adresse selv om grensesnittet er oppe. Det samme gjelder en socket-enhet som eier porten, og derfor er den første kontrollen alltid hva som faktisk lytter.

Sammenlign de to veiene etter destinasjonsadresse, ikke etter grensesnittnavn. En klient kobler til en adresse, og den adressen må være bundet før noen brannmurregel betyr noe.

List opp adressene og lytterne

Før du endrer noe, registrer adressene på verten og socketene som finnes nå.

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

Adresselisten viser hvilken privat adresse som er ekte og på hvilket grensesnitt, mens socketlisten viser om noe er bundet til den. En lytter på 0.0.0.0:22 godtar allerede hver adresse, så en ny binding legger ikke til noe. En lytter på én bestemt adresse forklarer avvisningen umiddelbart. Hvis porten tilhører en socket-enhet i stedet for daemonen, er daemonkonfigurasjonen ikke hele historien.

Legg til bindingen og behold den gamle

OpenSSH godtar flere ListenAddress-oppføringer, så VPN-veien kan bli værende mens den private legges til. Test filen før du laster den inn på nytt.

sshd -t
systemctl reload sshd

En mislykket konfigurasjonstest lar den kjørende daemonen være urørt, og det er nettopp det du vil mens du er tilkoblet over veien du endrer. Behold den eksisterende oppføringen, legg til den nye lokale adressen, og bekreft at tjenesten lastes inn på nytt uten å droppe den nåværende økten. På socket-aktiverte installasjoner legger du adressen til socket-enheten i stedet og laster den enheten på nytt. Les deretter lytterlisten på nytt, fordi en binding som aldri dukket opp betyr at feil komponent ble endret.

Verifiser den nye økten før du lukker den gamle

Koble til den nye adressen mens den opprinnelige økten fortsatt er åpen, og bruk detaljert utdata for å se hvilken adresse og nøkkel som ble brukt. Hold den opprinnelige økten åpen til testen lykkes to ganger.

ssh -v [email protected]

Les feilsøkingslinjene for destinasjonsadressen og vertsnøkkelen som ble presentert. Bekreft fingeravtrykket til vertsnøkkelen mot en verdi du allerede stoler på, i stedet for å godta en ukjent nøkkel fordi nettverket beskrives som privat. Den nye destinasjonen trenger sin egen known_hosts-oppføring, og det er forventet. Den gamle administrasjonsøkten bør først lukkes når den private veien virker.

SSH beskytter transporten, men det gjør ikke to nettverk likeverdige i seg selv. Bestem om tilliten til den private gjennomgangen passer til dataene før du stoler på den.