SSH па другім прыватным шляху, пакуль VPN працуе

Адзін камп'ютар дасягае іншага праз VPN, і цяпер камусьці патрэбна тая ж абалонка праз прыватную сетку правайдэра. Маршрут ёсць, ping праходзіць, а SSH усё роўна адмаўляе. Звычайная прычына ў тым, што дэман ніколі не слухаў новы адрас, таму падключацца няма да чаго. Гэта праблема прывязкі адраса раней, чым праблема файрвола.

Чаму новы маршрут не стварае новага слухача

Слухаючы сокет ствараецца працэсам, які вызначае адрасы, што ён будзе прымаць. Маршрут толькі паведамляе пакетам, куды ісці; ён не стварае слухача ў пункце прызначэння. Калі sshd наладжаны з адным ListenAddress, злучэнні на любы іншы лакальны адрас адхіляюцца, нават калі інтэрфейс уключаны. Тое ж датычыцца socket-юніта, які валодае портам, таму першая праверка заўсёды — што насамрэч слухае.

Параўнайце два шляхі па адрасе прызначэння, а не па назве інтэрфейса. Кліент падключаецца да адраса, і гэты адрас павінен быць прывязаны, перш чым любое правіла файрвола будзе мець значэнне.

Пералічыце адрасы і слухачоў

Перш чым нешта змяняць, запішыце адрасы на хосце і сокеты, якія існуюць цяпер.

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

Спіс адрасоў паказвае, які прыватны адрас сапраўдны і на якім інтэрфейсе, а спіс сокетаў — ці нешта прывязана да яго. Слухач на 0.0.0.0:22 ужо прымае ўсе адрасы, таму новая прывязка нічога не дадае. Слухач на адным канкрэтным адрасе адразу тлумачыць адмову. Калі порт належыць socket-юніту, а не дэману, канфігурацыя дэмана — не ўся гісторыя.

Дадайце прывязку і пакіньце старую

OpenSSH прымае некалькі запісаў ListenAddress, таму шлях VPN можа застацца, пакуль дадаецца прыватны. Праверце файл перад перазагрузкай.

sshd -t
systemctl reload sshd

Няўдалая праверка канфігурацыі пакідае працуючы дэман некранутым, і гэта менавіта тое, што патрэбна, пакуль вы падключаны праз шлях, які рэдагуеце. Пакіньце існуючы запіс, дадайце новы лакальны адрас і пераканайцеся, што служба перазагружаецца, не скідваючы бягучую сесію. На ўсталёўках з актывацыяй праз сокет дадайце адрас у socket-юніт і перазагрузіце гэты юніт. Затым зноў прачытайце спіс слухачоў, бо прывязка, якая так і не з'явілася, азначае, што адрэдагаваны не той кампанент.

Праверце новую сесію, перш чым закрыць старую

Падключыцеся да новага адраса, пакуль зыходная сесія яшчэ адкрыта, і выкарыстайце падрабязны вывад, каб убачыць, які адрас і ключ выкарыстаны. Трымайце зыходную сесію адкрытай, пакуль праверка не пройдзе двойчы.

ssh -v [email protected]

Прачытайце радкі адладкі пра адрас прызначэння і ключ хоста, які быў прапанаваны. Зверце адбітак ключа хоста са значэннем, якому вы ўжо давяраеце, замест таго каб прымаць невядомы ключ таму, што сетка называецца прыватнай. Новаму пункту прызначэння патрэбен уласны запіс known_hosts, і гэта чакана. Закрываць старую сесію кіравання варта толькі пасля таго, як прыватны шлях запрацуе.

SSH абараняе транспарт, але не робіць дзве сеткі эквівалентнымі сам па сабе. Вырашыце, ці адпавядае давер прыватнага транзіту даным, перш чым спадзявацца на яго.