Могу ли клијенти на два OpenVPN сервера да достигну једни друге?

Подизање другог OpenVPN сервера даје ти друго место на које клијенти могу да се повежу, и ништа више. Не ставља те клијенте на мрежу првог сервера, а опција названа client-to-client мења само прослеђивање унутар једног серверског процеса. Та два скупа постају једна мрежа када између њих рутираш намерно, са власником за сваки смер. Све испод претпоставља TUN режим у корисничком простору са искљученим тим унутрашњим прослеђивањем, тако да одлуку доноси кернел.

Мит: једна листа налога, једна мрежа

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

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

Дај сваком гејтвеју сопствени скуп и транзитну адресу

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

Одупри се напасти да оба сервера добију исти скуп како би профили остали идентични. Кернел рута не може да каже који од два хоста тренутно поседује произвољну адресу унутар заједничког опсега, па би табела рутирања показивала на један гејтвеј, а клијент би могао бити повезан на други. Називи интерфејса су локалне конвенције, не заједничко стање. Оба хоста овде тунелски уређај зову 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 је овде непотребан и активно штетан: превођење извора скрива који је клијент послао захтев и руши политику засновану на извору на страни одредишта. Провери да постојеће masquerade правило за излаз у интернет не хвата и ову стазу. Затим тестирај одбијање. Сервис који мора да остане локалан у скупу B мора да остане недоступан из скупа A, а парове клијената на истом гејтвеју такође треба тестирати, јер се измењена политика прослеђивања односи и на њих.

Још једна исправка менталног модела: транзитна веза преноси дешифроване унутрашње пакете, па је граница поверења, а не приватно јемство. Ако прелази мрежу коју не контролишеш, заштити тај хоп одобреним шифрованим тунелом и рутирај кроз његову стварну топологију. End-to-end TLS и даље сам аутентификује апликацију, зато би унутрашњи сервис требало да настави да га користи.