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

Поврзани статии