SSH egy második privát útvonalon, miközben a VPN aktív marad

Az egyik gép VPN-en keresztül éri el a másikat, és most valaki ugyanazt a shellt szeretné a szolgáltató privát hálózatán. Az útvonal létezik, a ping sikerül, az SSH mégis elutasít. A szokásos ok, hogy a démon soha nem figyelt az új címen, így nincs mihez csatlakozni. Ez címkötési probléma, mielőtt tűzfalprobléma lenne.

Miért nem hoz létre új figyelőt egy új útvonal

A figyelő socketet egy folyamat hozza létre, amely megnevezi azokat a címeket, amelyeken fogad. Az útvonal csak megmondja a csomagoknak, hova menjenek; nem hoz létre figyelőt a célhelyen. Ha az sshd egyetlen ListenAddress bejegyzéssel van beállítva, a többi helyi címre érkező kapcsolatokat elutasítja, pedig az interfész aktív. Ugyanez érvényes arra a socket-egységre, amely a portot birtokolja, ezért az első ellenőrzés mindig az, hogy valójában mi figyel.

A két útvonalat a célcím alapján hasonlítsa össze, ne az interfész neve alapján. Az ügyfél egy címhez csatlakozik, és ezt a címet előbb hozzá kell kötni, mint hogy bármely tűzfalszabály számítana.

A címek és a figyelők felsorolása

Mielőtt bármit szerkesztene, jegyezze fel a hoszton lévő címeket és a jelenleg létező socketeket.

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

A címlista megmutatja, melyik privát cím valódi és melyik interfészen, a socketlista pedig azt, hogy kötődik-e hozzá valami. A 0.0.0.0:22 címen figyelő démon már minden címet fogad, így az új kötés semmit nem ad hozzá. Egy adott címen figyelő démon azonnal megmagyarázza az elutasítást. Ha a port egy socket-egységhez tartozik, nem a démonhoz, akkor a démon beállítása nem a teljes történet.

Adja hozzá a kötést, és tartsa meg a régit

Az OpenSSH több ListenAddress bejegyzést is elfogad, így a VPN-útvonal megmaradhat, miközben a privát hozzáadódik. Újratöltés előtt tesztelje a fájlt.

sshd -t
systemctl reload sshd

A sikertelen konfigurációs teszt érintetlenül hagyja a futó démont, és pontosan erre van szüksége, miközben azon az útvonalon csatlakozik, amelyet szerkeszt. Tartsa meg a meglévő bejegyzést, adja hozzá az új helyi címet, és erősítse meg, hogy a szolgáltatás az aktuális munkamenet megszakítása nélkül töltődik újra. Socket-aktivált telepítéseken a címet a socket-egységhez adja hozzá, és azt az egységet töltse újra. Ezután olvassa el újra a figyelők listáját, mert a soha meg nem jelent kötés azt jelenti, hogy rossz összetevőt szerkesztett.

Az új munkamenet ellenőrzése a régi lezárása előtt

Csatlakozzon az új címhez, miközben az eredeti munkamenet még nyitva van, és részletes kimenettel nézze meg, melyik címet és kulcsot használta. Addig tartsa nyitva az eredeti munkamenetet, amíg a próba kétszer nem sikerül.

ssh -v [email protected]

Olvassa el a célcímhez és a bemutatott hostkulcshoz tartozó hibakeresési sorokat. A hostkulcs ujjlenyomatát egy már megbízható értékhez hasonlítsa, ahelyett hogy ismeretlen kulcsot fogadna el azért, mert a hálózatot privátként írták le. Az új célhelynek saját known_hosts bejegyzésre van szüksége, és ez várható. A régi felügyeleti munkamenetet csak akkor zárja le, amikor a privát útvonal már működik.

Az SSH védi az átvitelt, de önmagában nem tesz egyenlővé két hálózatot. Döntse el, hogy a privát átvitel bizalma megfelel-e az adatoknak, mielőtt támaszkodna rá.