SSH teisel privaatsel teel, kui VPN jääb tööle

Üks masin jõuab teiseni VPN-i kaudu ja nüüd tahab keegi sama shelli teenusepakkuja privaatvõrgus. Marsruut on olemas, ping õnnestub ja SSH keeldub siiski. Tavaline põhjus on see, et deemon ei kuulanud kunagi uuel aadressil, seega pole millegagi ühenduda. See on aadressi sidumise probleem enne, kui see on tulemüüri probleem.

Miks uus marsruut uut kuulajat ei loo

Kuulavat pesa loob protsess, mis nimetab aadressid, mida ta vastu võtab. Marsruut ainult ütleb pakettidele, kuhu reisida; see ei loo sihtkohas kuulajat. Kui sshd on seadistatud ühe ListenAddress-iga, keeldutakse ühendustest mis tahes muule kohalikule aadressile, isegi kui liides on üleval. Sama kehtib pesaüksuse kohta, mis porti omab, ja seetõttu on esimene kontroll alati see, mis tegelikult kuulab.

Võrrelge kahte teed sihtaadressi, mitte liidese nime järgi. Klient ühendub aadressiga ja see aadress peab olema seotud enne, kui mis tahes tulemüürireegel loeb.

Loetlege aadressid ja kuulajad

Enne millegi muutmist kirjutage üles hosti aadressid ja pesad, mis praegu olemas on.

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

Aadresside loend näitab, milline privaatne aadress on tegelik ja millisel liidesel, samas kui pesade loend näitab, kas midagi on sellega seotud. Kuulaja aadressil 0.0.0.0:22 võtab juba vastu kõik aadressid, seega uus sidumine ei lisa midagi. Kuulaja ühel kindlal aadressil selgitab keeldumist kohe. Kui port kuulub pesaüksusele, mitte deemonile, ei ole deemoni seadistus kogu lugu.

Lisage sidumine ja jätke vana alles

OpenSSH võtab vastu mitu ListenAddress-kirjet, seega VPN-i tee võib jääda, samal ajal kui privaatne lisatakse. Testige faili enne selle uuesti laadimist.

sshd -t
systemctl reload sshd

Ebaõnnestunud seadistuse test jätab töötava deemoni puutumata ja just seda te tahad, kui oled ühendatud tee kaudu, mida muudad. Jätke olemasolev kirje alles, lisage uus kohalik aadress ja kinnitage, et teenus laaditakse uuesti, kaotamata praegust sessiooni. Pesaaktiveeritud paigaldustes lisage aadress hoopis pesaüksusele ja laadige see üksus uuesti. Seejärel lugege kuulajate loendit uuesti, sest sidumine, mis kunagi ei ilmunud, tähendab, et muudeti vale komponenti.

Kontrollige uut sessiooni enne vana sulgemist

Ühenduge uue aadressiga, kui algne sessioon on veel avatud, ja kasutage üksikasjalikku väljundit, et näha, millist aadressi ja võtit kasutati. Hoidke algne sessioon avatud, kuni katse õnnestub kaks korda.

ssh -v [email protected]

Lugege silumisridu sihtaadressi ja esitatud hostivõtme kohta. Kinnitage hostivõtme sõrmejälg väärtusega, mida te juba usaldate, selle asemel et võtta vastu tundmatu võti, sest võrku kirjeldatakse privaatsena. Uus sihtkoht vajab oma known_hosts-kirjet ja see on ootuspärane. Alles siis, kui privaatne tee töötab, tuleks vana haldussessioon sulgeda.

SSH kaitseb transporti, kuid ei tee kahte võrku iseenesest samaväärseks. Otsustage, kas privaatse transiidi usaldus vastab andmetele, enne kui sellele loote.