Нека един клиент на OpenVPN прави SSH към друг, без да се отваря пулът

Оставете client-to-client изключен, дайте на ядрото да препраща един поток, а останалата част от пула да остане затворена. Две правила на сървъра и едно на дестинацията.

Един клиент трябва да достигне SSH услугата на друг клиент, а останалата част от пула да остане също толкова изолирана, колкото е днес. Изкушаващият ключ е client-to-client, който включва достъп между равностойните за всички наведнъж и предава решението на OpenVPN вместо на ядрото. По-тесният отговор оставя този ключ изключен и позволява на маршрутизацията и защитната стена на самия сървър да носят точно един поток.

Механизмът е по-важен от текста на правилото, защото двата подхода поставят пакета на различни места. Знанието кой сте избрали обяснява както правилото, което сякаш не прави нищо, така и равностойния клиент, който се свързва без него.

Къде client-to-client премества пакета

Когато client-to-client е включен, сървърът препраща пакета на равностойния клиент вътрешно, вместо да го изпрати отново навън през тунелното устройство, така че пакетът никога не стига до пътя за препращане на ядрото. Това е удобно и означава също, че защитната ви стена никога не вижда потока, който би трябвало да наблюдава. Оставете опцията изключена и сървърът насочва пакета отново навън през същия интерфейс, което го поставя пред netfilter. Същият интерфейс влиза, същият излиза, и веригата FORWARD има думата.

Размяната е ясна: печелите точка за политика и поемате маршрутизацията и препращането, които пряката пътека вършеше вместо вас. Тази работа е малка за един поток и расте с всяко изключение, което добавите. Пребројте изключенията сега, защото именно в набора от правила наистина живее политиката между равностойните клиенти.

Пътят, който пакетът на равностойния клиент наистина изминава

Да приемем услуга Linux Community OpenVPN 2.6, обработка на TUN в потребителското пространство, а не DCO, топология на подмрежа, tun0 и пул от 10.44.0.0/24 с клиент A на 10.44.0.21 и клиент B на 10.44.0.37. При топология на подмрежа адресът и маската, които A е получил, вече покриват пула, затова A изпраща пакета към тунелното устройство без нужда от допълнителен избутван маршрут. Проверете действителния маршрут на A, вместо да предполагате такъв.

На сървъра пакетът пристига адресиран до B, което не е локален адрес, затова се препраща. Препращането на IPv4 трябва да е включено, за да се случи това изобщо, и търсенето на маршрут трябва да изпрати пакета отново навън през tun0. Затова защитната стена вижда препратен поток със същия интерфейс от двете страни, и това е подробността, която повечето набори от правила пропускат. Тук не е нужен превод на източника, и именно запазването на адреса на A непокътнат позволява на B да приложи собственото си правило, основано на източника.

Две правила на сървъра, в този ред

Три правила носят цялото разрешение: препращането, изключението за двойката и подразбиращо се отхвърляне за тунелната двойка. Правилото за приемане назовава двойката и услугата, затова разрешението оцелява при растящ пул. Поставете го преди всяка обща забрана на трафик тунел-към-тунел, защото печели първото съвпадение:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Тези команди са илюстративни и принадлежат на механизма, който вашият хост използва, за да запазва правила; вмъкване по време на работа изчезва при следващото зареждане. Именно правилото със състояние позволява отговорите на B и ръкостискането на TCP да се върнат без второ, огледално приемане.

Проверете броячите след това, а не списъка с правила, защото правило, което никога не съвпада, изглежда идентично на работещо. Ако броячите останат на нула, пакетът не следва пътя, който мислите.

Какво B все още трябва да разреши

B изпълнява SSH услугата, затова B решава дали нещо слуша на тунелния адрес и дали собствената му защитна стена на хоста приема източника. Мрежово разрешение на сървъра не е разрешение за който и да е акаунт на B, а проверката на ключа на хоста и удостоверяването на потребителя продължават да важат както от всяко друго място.

Първо проверете положителния случай: нова SSH връзка от A към тунелния адрес на B, приета с очаквания ключ на хоста. След това проверете друг равноправен клиент или друг порт и потвърдете, че е отказан, защото разрешение, което тихо позволява всичко, е неразличимо от работещо, докато не стане важно. И двете половини на този тест са необходими, а втората е тази, която хората пропускат.

Запишете назначените адреси, действителните маршрути на двата клиента и точните правила на сървъра и на B. Успешен ping към шлюза или отворен порт на сървъра не доказва нищо от това, тъй като и двете могат да са верни, докато препращането между равностойните клиенти все още е блокирано. Запишете тези числа, докато тунелът е вдигнат, защото адресът, който клиентът получава след повторно свързване, може да е друг.

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