Дозволете еден 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 до портата или отворен порт на серверот не докажува ништо од ова, бидејќи и двете можат да бидат вистинити додека препраќањето меѓу рамноправните е се уште блокирано. Запишете ги тие бројки додека тунелот е подигнат, бидејќи адресата што клиентот ја добива по повторно поврзување може да биде друга.

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