Maaari bang maabot ng mga kliyente sa dalawang OpenVPN server ang isa't isa?

Ang pagtatayo ng pangalawang OpenVPN server ay nagbibigay sa iyo ng pangalawang lugar kung saan makakakonekta ang mga kliyente, at wala nang iba pa. Hindi nito inilalagay ang mga kliyenteng iyon sa network ng unang server, at ang opsyong tinatawag na client-to-client ay nagbabago lamang ng pagpapasa sa loob ng isang proseso ng server. Ang dalawang pool ay nagiging isang network kapag nag-route ka sa pagitan nila nang sadya, may may-ari para sa bawat direksyon. Ipinapalagay ng lahat sa ibaba ang TUN mode sa userspace na patay ang panloob na pagpapasa, kaya ang kernel ang nagpapasya.

Ang mito: isang listahan ng account, isang network

Pinaghalo ang pagpapatotoo at pag-abot dahil pareho silang nasa configuration ng server. Ang isang user na makakapag-log in sa alinman sa dalawang gateway ay mukhang, mula sa labas, isang user sa isang system na may dalawang pinto. Sa loob, bawat server ay nagbibigay ng address mula sa sariling pool at naglalagay ng ruta para lamang sa mga kliyenteng tinatapos nito. Kaya ang isang kliyente sa gateway A na nagpapadala ng packet sa isang kliyente sa gateway B ay humihingi ng destinasyong hindi pa narinig ng sarili nitong server. Ang packet ay pumupunta sa default na ruta ng A, lumalabas sa tunnel, at dumarating sa isang firewall na hindi kailanman hinilingang payagan ito.

Ang pagdaragdag ng pangalawang server ay hindi nagdaragdag ng redundancy, discovery o pinagsasaluhang broadcast domain. Nagdaragdag ito ng naka-route na network na nangangailangan ng plano, at ang plano ay nagsisimula sa pag-address.

Bigyan ang bawat gateway ng sariling pool at transit address

Dalawang saklaw na hindi maaaring mag-overlap sa anupaman, kasama ang maliit na transit link sa pagitan ng mga host, ang buong plano ng address. Panatilihin ang transit sa pribadong segment na kontrolado mo, at isulat ang mga numero bago magbigay ng lease ang alinmang server.

Labanan ang tuksong bigyan ang dalawang server ng parehong pool para manatiling pareho ang mga profile. Hindi masasabi ng ruta ng kernel kung alin sa dalawang host ang kasalukuyang nagmamay-ari ng anumang address sa loob ng pinagsasaluhang saklaw, kaya ang routing table ay tuturo sa isang gateway at ang kliyente ay maaaring nakakabit sa isa pa. Ang mga pangalan ng interface ay lokal na kaugalian, hindi pinagsasaluhang estado. Tinatawag ng dalawang host dito ang tunnel device na tun0 at ang transit link na transit0, na ayos lang dahil walang packet na nagdadala ng mga pangalang iyon.

I-install ang ruta sa magkabilang panig

Kailangan ng bawat gateway ng ruta patungo sa pool ng isa pa sa pamamagitan ng transit address, at kailangang bukas ang pagpapasa para makilos ang alinman bilang hop. Kumpirmahin muna ang kasalukuyang table, pagkatapos idagdag ang entry at gawin itong permanente sa pamamagitan ng network manager ng host sa halip na isang hook ng muling pagkonekta.

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

I-mirror ito sa kabilang host na pinagpalit ang mga pool. Ang paulit-ulit na pagdaragdag ng parehong ruta mula sa walang kaugnayang script ang paraan para magkaroon ang isang host ng ilang kopya at mahiwagang pagbabago sa susunod na may magbasa ng table. Kung ang transit link mismo ay isang tunnel, ang ruta ay tuturo sa topolohiya ng tunnel na iyon at ang hop ay dapat mabuhay pagkatapos ng muling pagkonekta nito. Ang transit address na nawawala nang tatlumpung segundo ay nagdadala ng landas sa pagitan ng mga pool, isang katangian ng disenyo na dapat sabihin kaysa matuklasan.

Itulak ang ruta ng kliyente nang hindi nagpapanggap na may-ari

Kailangan ng mga kliyente ng ruta patungo sa malayong pool, kung hindi ipapadala ng sarili nilang operating system ang packet sa default na gateway at hindi ito makikita ng tunnel. Ang configuration ng server ang natural na lugar para ihatid ito.

push "route 10.64.20.0 255.255.255.0"

Ilagay ang mirror line sa configuration ng kabilang server, pagkatapos ikonekta muli ang isang test client at basahin ang table nito. Ang kliyenteng binabalewala ang mga itinulak na ruta ay kailangan ng sariling aprubadong configuration, at ang rutang hindi dumarating ay hindi kontrol ng access. Huwag bigyan ang isang kliyente ng iroute para sa buong pool ng kabilang gateway. Umiiral ang direktibang iyon para sa subnet sa likod ng isang konektadong kliyente, at ang paggamit nito para takpan ang kulang na ruta sa pagitan ng mga gateway ay gumagawa ng server na naniniwalang pag-aari nito ang mga address na hindi niya maabot.

Patunayan ang isang kahilingan at tanggihan ang isa pa

Pumili ng tunay na operasyon, halimbawa HTTPS mula sa isang kliyente sa 10.64.10.21 patungo sa isang serbisyo sa 10.64.20.37, at payagan nang eksakto iyon sa dalawang host. Tinatanggap ng bawat firewall ang kahilingan sa papasok na gilid at ang sinusubaybayang tugon sa pabalik na gilid; kailangan pa ring tanggapin iyon ng sariling patakaran ng serbisyo ng destinasyon.

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

Kapag may magkabilang ruta, ang source NAT ay hindi kailangan at aktibong nakakasama dito: ang pagsasalin ng source ay nagtatago kung sinong kliyente ang gumawa ng kahilingan at sinisira ang patakarang nakabatay sa source sa gilid ng destinasyon. Tiyakin na ang umiiral na masquerade rule para sa paglabas sa internet ay hindi rin nahuhuli ang landas na ito. Pagkatapos subukan ang pagtanggi. Ang serbisyong dapat manatiling lokal sa pool B ay dapat manatiling hindi maabot mula sa pool A, at ang mga pares ng kliyente sa parehong gateway ay kailangan ding subukan, dahil ang patakaran ng pagpapasa na binago mo lang ay nalalapat din sa kanila.

Isa pang pagwawasto sa mental na modelo: ang transit link ay nagdadala ng na-decrypt na panloob na packet, kaya ito ay hangganan ng pagtitiwala at hindi pribadong garantiya. Kung tatawid ito sa network na hindi mo kontrolado, protektahan ang hop na iyon gamit ang aprubadong naka-encrypt na tunnel at i-route sa tunay nitong topolohiya. Ang end-to-end TLS ay patuloy pa ring nagpapatotoo sa aplikasyon nang mag-isa, kaya dapat ipagpatuloy ito ng panloob na serbisyo.