Дозволите један 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, subnet топологију, tun0 и пул од 10.44.0.0/24 са клијентом A на 10.44.0.21 и клијентом B на 10.44.0.37. Код subnet топологије адреса и маска које је 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 до гејта или отворен порт на серверу не доказује ништа од овога, јер обоје може бити тачно док је прослеђивање међу клијентима још блокирано. Запишите те бројеве док је тунел подигнут, јер адреса коју клијент добије након поновног повезивања може бити друга.

Повезани чланци