Защо правило за порт на източника чупи един от вашите 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.

Подобни статии