Isang TAP server o marami? Mga OpenVPN client sa isang bridge

Ang maraming TAP client ay hindi nangangailangan ng isang server process, isang UDP port at isang TAP device sa host para sa bawat isa. Ang isang OpenVPN server sa Ethernet mode ay maaaring tumanggap ng maraming authenticated client at ikabit sila sa isang bridge, at iyon ang dokumentadong paraan upang palawakin ang isang segment ng layer 2. Ang disenyong may isang proseso ang dokumentado ng manwal, at kadalasan iyon ang tamang default.

Ang tunay na tanong ay kung dapat bang ibahagi ng mga client na iyon ang segment na iyon. Hindi iyon sinasagot ng bilang ng proseso, dahil nagmumula ang mga katangian ng paghihiwalay sa topology at hindi sa kung ilang daemon ang tumatakbo. Ang natitirang bahagi ng paghahambing na ito ay tungkol sa dalawang topology at sa kung ano ang pinapadali ng bawat isa.

Dalawang arkitektura, hindi dalawang setting

Ang naka-route na TUN deployment ay nagbibigay sa bawat client ng point-to-point na link papasok sa routing domain ng server. Humihinto ang mga broadcast sa server, hindi nakikita ng mga client ang mga frame ng isa't isa, at ang trapiko sa pagitan ng mga client, kung mayroon, ay dapat tahasang i-route at i-filter.

Ang naka-bridge na TAP deployment ay ginagawang miyembro ng isang Ethernet segment ang mga client. Nakikita nila ang mga broadcast, maaari nilang hanapin ang isa't isa sa ARP, at umaasa sila sa patakaran ng bridge at firewall sa halip na routing upang manatiling hiwalay. Kapaki-pakinabang iyon kapag kailangang magmukhang nakasaksak sa parehong switch ang mga client.

Kaya ang paghahambing ay tungkol sa kung ano ang dapat marating ng mga client, hindi sa performance. Piliin muna ang layer, pagkatapos ay magpasya kung ilang proseso ang maglilingkod dito.

Ano ang ginagawa ng server-bridge helper

Ang helper na server-bridge ay nag-configure ng multi-client na Ethernet mode. Ang anyo nitong address pool ay tumatanggap ng gateway, netmask at nakalaang saklaw sa loob ng naka-bridge na subnet, halimbawa gateway sa 192.168.50.1 na may pool mula 192.168.50.160 hanggang 192.168.50.199.

Ilaan ang saklaw na iyon sa labas ng anumang iba pang pagtatalaga ng DHCP o static. Naglalaan ang helper ng mga address mula rito, ngunit hindi ito nakikipag-ugnayan sa ibang tagapaglaan sa parehong segment, at dalawang pool na nagsasapawan ay gumagawa ng doble na address na mukhang random na pagkabigo ng koneksyon. Isulat ang nakalaang saklaw sa plano ng address ng site upang hindi na ito gamitin ng susunod na tao. Ang komento sa configuration ng server ay mahinang kapalit ng talaang iyon.

May anyo na may DHCP proxy para sa mga deployment kung saan ang panlabas na server ang nagbibigay ng address. May sarili itong mga paunang kundisyon, at ang paghahalo ng dalawang anyo ay gumagawa ng eksaktong salungatan na binabalaan ng dokumentasyon. Pumili ng isang tagapaglaan para sa naka-bridge na subnet.

Ang paghihiwalay ay hindi nagmumula sa bilang ng proseso

Ang walong proseso ng OpenVPN na nakakabit sa parehong walang limitasyong bridge ay nagbabahagi pa rin ng isang broadcast domain. Maaaring magpadala ang mga client ng ARP sa isa't isa sa buong bridge, at walang binago ang bilang ng tagapakinig doon.

Kung ang pangangailangan ay hindi dapat makita ng mga grupo ng client ang isa't isa sa layer 2, kailangan ng disenyo ng hiwalay na bridge o koneksyon ng VLAN, kasama ang mga patakaran sa pag-access na kasama nila. Ito ay desisyon sa disenyo ng network, at pareho ito kung isang server process o walo ang kasangkot. Ang pag-filter ng bridge ay maaaring maglimita ng bahagi ng trapiko, ngunit hindi ito gumagawa ng hiwalay na broadcast domain. Ituring itong pandagdag sa segmentation, hindi kapalit nito.

Kung ang pangangailangan ay lamang na maabot ng mga client ang ilang serbisyo ng IP, ang naka-route na TUN na disenyo ay karaniwang mas simple kaysa sa pag-bridge kasama ang pag-filter. Bawat client ay nakakakuha ng sariling link, at ang patakaran ay nasa mga tuntunin ng routing at firewall sa halip na sa loob ng bridge.

Kailan tama pa rin ang maraming proseso

Ang hiwalay na mga proseso ay maaaring bigyang-katwiran ng mga pangangailangan sa operasyon: iba't ibang backend ng authentication, iba't ibang awtoridad ng sertipiko, hiwalay na cycle ng pag-upgrade, o hindi magkatugmang set ng opsyon. Tunay na mga dahilan ang mga ito at independyente sa bilang ng client.

Kung gumamit ka ng marami, bigyan ang bawat isa ng sariling listener at pagmamay-ari ng device, at i-coordinate ang mga saklaw ng address. Dalawang server na parehong naniniwalang pagmamay-ari nila ang parehong pool sa parehong bridge ay magbibigay din ng parehong address.

Pagkatapos, i-verify ang disenyo gamit ang maraming client nang sabay. Suriin na natatangi ang mga address, gumagana ang inaasahang trapiko sa pagitan ng mga client, at hindi magawa ng pares na hindi dapat mag-usap. Ang matagumpay na ping ng isang client ay walang sinusubok sa disenyong may maraming client.

Basahin ang bridge at ang mode ng server mula sa tumatakbong host bago magtiwala sa diagram. Ang configuration na mahalaga ay ang aktwal na na-load ng kernel at daemon, at iyon din ang maaaring suriin ng isang reviewer.