Чаму правіла зыходнага порта ламае адзін з вашых шляхоў SSH

Супадзенне «sport 22» не кажа, да якога ўваходу SSH належыць адказ. Абмяжуйце правіла палітыкі кіраваннем, а не адной табліцай толькі для WAN.

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

Два ўваходы, адзін порт службы

Хаст мае адрас з боку LAN і адрас VPN, і sshd слухае на абодвух. Таму прамая сесія і тунельная сесія дзеляць порт службы і розняцца толькі тым, які лакальны адрас прымае злучэнне.

Гэтай розніцы дастаткова, каб выбраць шлях адказу, і гэта менавіта тая розніца, якую правіла на аснове порта адкідвае. Абедзве сесіі ствараюць адказы з зыходным портам 22, таму правіла, якое супадае з гэтым портам, не можа іх падзяліць. Яно накіроўвае абодва пошукі ў адну табліцу, і адзін з іх атрымлівае адказ, які не падыходзіць. Выпраўленне — супаставіць атрыбут, які сапраўды розніцца.

Даць кожнаму ўваходу свой порт таксама спрацавала б, і разглядаць гэта як патрабаванне — гэта выбар дызайну, а не ўласцівасць SSH.

Чытайце правіла, потым чытайце табліцу

Правіла палітыкі — гэта ўпарадкаваны селектар, і першае, якое вяртае прыдатны адказ, завяршае пошук. Чытайце спіс па парадку і адзначце, якое правіла можа перамагчы.

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

ip -4 rule show
ip route show table 100
ip route show table main

Абодва вывады разам тлумачаць вынік; любы з іх паасобку запрашае няправільную выснову.

Абмяжуйце правіла патрэбным патокам

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

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

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

Трымайце асобна слухача, дазвол і выбар адказу

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

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

Трымайце канал аднаўлення, які не залежыць ад шляху, які вы змяняеце, бо памылка тут замыкае само выпраўленне.

Дакажыце гэта новай сесіяй, а не старой

Усталяваны тэрмінал нічога не даказвае, бо ён быў дапушчаны да змены. Адкрыйце свежую сесію праз кожны меркаваны ўваход.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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

Падобныя артыкулы