SSH på ein andre privat veg medan VPN-en er oppe

Éi maskin når ei anna over ein VPN, og nokon vil no ha same skal over eit privat nettverk hos leverandøren. Ruta finst, ping lukkast, og SSH nektar framleis. Den vanlege årsaka er at demonen aldri lytta på den nye adressa, så det er ingenting å kopla til. Dette er eit adressebindingsproblem før det er eit brannmurproblem.

Kvifor ei ny rute ikkje lagar ein ny lyttar

Ein lyttande socket vert oppretta av ein prosess som namngjev adressene han vil godta. Ei rute fortel berre pakkane kvar dei skal reise; ho lagar ikkje ein lyttar på destinasjonen. Når sshd er konfigurert med éin ListenAddress, vert tilkoplingar til kvar annan lokal adresse avviste sjølv om grensesnittet er oppe. Det same gjeld ei socket-eining som eig porten, og difor er den første kontrollen alltid kva som faktisk lyttar.

Samanlikn dei to vegane etter destinasjonsadresse, ikkje etter grensesnittnamn. Ein klient koplar til ei adresse, og den adressa må vera bunden før noka brannmurregel tyder noko.

List opp adressene og lyttarane

Før du endrar noko, registrer adressene på verten og socketane som finst no.

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

Adresselista viser kva privat adresse som er ekte og på kva grensesnitt, medan socketlista viser om noko er bundet til ho. Ein lyttar på 0.0.0.0:22 godtek allereie kvar adresse, så ei ny binding legg ikkje til noko. Ein lyttar på éi bestemt adresse forklarar avvisinga med ein gong. Viss porten høyrer til ei socket-eining i staden for demonen, er demonkonfigurasjonen ikkje heile historia.

Legg til bindinga og behald den gamle

OpenSSH godtek fleire ListenAddress-oppføringar, så VPN-vegen kan bli verande medan den private vert lagd til. Test fila før du lastar ho inn på nytt.

sshd -t
systemctl reload sshd

Ein mislukka konfigurasjonstest let den køyrande demonen vera urørt, og det er nettopp det du vil medan du er tilkopla over vegen du endrar. Behald den eksisterande oppføringa, legg til den nye lokale adressa, og stadfest at tenesta vert lasta inn på nytt utan å droppa den noverande økta. På socket-aktiverte installasjonar legg du adressa til socket-eininga i staden og lastar den eininga på nytt. Les deretter lyttarlista på nytt, fordi ei binding som aldri dukka opp tyder at feil komponent vart endra.

Stadfest den nye økta før du lukkar den gamle

Kopla til den nye adressa medan den opphavlege økta framleis er open, og bruk detaljert utdata for å sjå kva adresse og nøkkel som vart brukte. Hald den opphavlege økta open til testen lukkast to gonger.

ssh -v [email protected]

Les feilsøkingslinjene for destinasjonsadressa og vertsnøkkelen som vart presentert. Stadfest fingeravtrykket til vertsnøkkelen mot ein verdi du allereie stolar på, i staden for å godta ein ukjend nøkkel fordi nettverket er skildra som privat. Den nye destinasjonen treng si eiga known_hosts-oppføring, og det er venta. Den gamle administrasjonsøkta bør først lukkast når den private vegen verkar.

SSH vernar transporten, men det gjer ikkje to nettverk likeverdige i seg sjølv. Avgjer om tilliten til den private gjennomgangen passar til dataa før du stolar på han.