Можат ли клиентите на два OpenVPN сервери да се достигнат меѓусебно?

Поставувањето втор OpenVPN сервер ви дава второ место каде клиентите можат да се поврзат, и ништо повеќе. Тоа не ги става тие клиенти на мрежата на првиот сервер, а опцијата client-to-client ја менува само препраќањето во еден серверски процес. Двата базени стануваат една мрежа кога намерно насочувате меѓу нив, со одговорен за секој правец. Сè подолу претпоставува TUN режим во кориснички простор со исклучено тоа внатрешно препраќање, така што одлуката ја носи јадрото.

Мит: еден список сметки, една мрежа

Автентикацијата и достапноста се мешаат зашто двете живеат во конфигурацијата на серверот. Корисник што може да се најави на кој било од двата порти, однадвор изгледа како корисник на еден систем со две врати. Внатре, секој сервер доделува адреси од својот базен и поставува рути само за клиентите што ги завршува. Затоа клиент на портата A што праќа пакет до клиент на портата B бара дестинација за која неговиот сервер никогаш не слушнал. Пакетот оди по стандардната рута на A, ја напушта тунелот и пристигнува на огнен ѕид што никогаш не бил замолен да го дозволи.

Затоа додавањето втор сервер не додава резерва, откривање или заеднички емитувачки домен. Додава насочена мрежа што бара план, а планот почнува со адресирање.

Дајте и на секоја порта сопствен базен и транзитна адреса

Два опсези што не можат да се преклопуваат со ништо друго, плус мала транзитна врска меѓу домаќините, е целиот адресен план. Држете го транзитот на приватен сегмент што го контролирате и запишете ги бројките пред кој било сервер да издаде закуп.

Спротивставете се на искушението да им дадете и на двата сервери ист базен за профилите да останат идентични. Рута во јадрото не може да каже кој од два домаќини во моментов поседува произволна адреса во заеднички опсег, па табелата за насочување би покажувала кон една порта, а клиентот може да е поврзан на другата. Имињата на интерфејсите се локални конвенции, не заедничка состојба. Двата домаќини овде тунелскиот уред го викаат tun0, а транзитната врска transit0, што е во ред зашто ниту еден пакет не ги носи тие имиња.

Инсталирајте ја рутата од двете страни

На секоја порта и треба рута до базенот на другата преку транзитната адреса, а препраќањето мора да биде вклучено за која било да дејствува како скок. Најпрво потврдете ја тековната табела, потоа додајте го записот и направете го трајно преку мрежниот менаџер на домаќинот наместо преку кука за повторно поврзување.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Огледално повторете го тоа на другиот домаќин со заменети базени. Повторното додавање на истата рута од неповрзан скрипта е начинот на кој домаќинот завршува со неколку копии и мистериозна промена следниот пат кога некој ќе ја прочита табелата. Ако транзитната врска сама е тунел, рутата покажува кон топологијата на тој тунел и скокот мора да го преживее неговото повторно поврзување. Транзитна адреса што исчезнува триесет секунди го зема со себе и патот меѓу базените, што е својство на дизајнот што вреди да се објави, а не да се открие.

Турнете ја рутата на клиентот без да измислувате сопственост

На клиентите им треба рута до оддалечениот базен, инаку нивниот оперативен систем го праќа пакетот на стандардната порта и тунелот никогаш не го гледа. Конфигурацијата на серверот е природното место да го достави тоа.

push "route 10.64.20.0 255.255.255.0"

Ставете ја огледалната линија во конфигурацијата на другиот сервер, потоа поврзете го повторно пробниот клиент и прочитајте ја неговата табела. Клиент што ги игнорира турнатите рути треба сопствена одобрена конфигурација, а рута што никогаш не пристигнува не е контрола на пристап. Не давајте на клиент iroute за целиот базен на другата порта. Таа директива постои за подмрежа зад еден поврзан клиент, а нејзината употреба за покривање на рута што недостасува меѓу портите создава сервер што верува дека поседува адреси до кои не може да дојде.

Докажете едно барање и одбијте друго

Изберете вистинска операција, на пример HTTPS од клиент на 10.64.10.21 до услуга на 10.64.20.37, и дозволете точно тоа на двата домаќини. Секој огнен ѕид го прифаќа барањето на својата влезна страна и следениот одговор на страната за враќање; сопствената услужна политика на дестинацијата сепак треба да го прифати.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Со взаемни рути, NAT на изворот е непотребен и овде активно штетен: преведувањето на изворот крие кој клиент го поднел барањето и ја поразува политиката заснована на извор на страната на дестинацијата. Проверете дали постоечкото правило за маскирање за излез на интернет не го фаќа и овој пат. Потоа тестирајте го одбивањето. Услуга што треба да остане локална за базен B мора да остане недостапна од базен A, а паровите клиенти на иста порта исто така треба да се тестираат, бидејќи политиката за препраќање што штотуку ја сменивте важи и за нив.

Уште една исправка на менталниот модел: транзитната врска пренесува дешифрирани внатрешни пакети, значи е граница на доверба, а не приватна гаранција. Ако минува низ мрежа што не ја контролирате, заштитете го тој скок со одобрен шифриран тунел и насочувајте низ неговата вистинска топологија. Крај-до-крај TLS сè уште самата ја автентикува апликацијата, затоа внатрешната услуга треба да продолжи да ја користи.