Ang Sophos RED ay isang papel para sa malayong site at hindi protokol ng VPN, kaya ang paghahambing nito sa IPsec o OpenVPN ay sumasagot sa maling tanong. Pinalalawak ng device ang kontrol ng sentral na firewall patungo sa sangay, at ang mode na pipiliin mo ang nagtatakda kung sino ang nagbibigay ng gateway ng sangay, sino ang namamahagi ng address at aling trapiko ang dumadaan sa tunnel. Mas mabigat ang tatlong sagot na iyon kaysa sa mga pangalan ng mode. Ang pagsulat sa kanila muna ay ginagawang desisyon sa disenyo ang pagpili ng produkto.

Papel ang RED, hindi protokol

Ikinokonekta ng RED device ang isang sangay sa sentral na Sophos Firewall, at ang configuration ng firewall ang nagtatakda kung ano ang magiging sangay. Ang tunnel ay detalyeng implementasyon ng koneksyong iyon, hindi isang pangkalahatang VPN endpoint na maaaring itutok sa kahit anong kapares.

Mahalaga ang balangkas na iyon dahil ang RED ay hindi mapapalitan ng kahit anong IPsec na kapares. Inaasahan nitong pinamamahalaan ito ng sentral na firewall, at inilalarawan ng mga sinusuportahang mode kung gaano karami sa sangay ang kinukuha nito. Ang pagtrato dito na ordinaryong tunnel endpoint ay lumilikha ng mga inaasahan na hindi kailanman ipinangako ng produkto. Ang pagtrato dito bilang papel ay naglalabas ng mga tanong na talagang nagtatakda ng disenyo.

Binabago ng tatlong kundisyon sa ibaba ang sagot, at lahat sila ay tungkol sa pagmamay-ari, hindi sa encryption.

Tatlong kundisyon na pumipili ng mode

Itanong kung sino ang may-ari ng gateway ng sangay, sino ang nagpapatakbo ng DHCP at DNS para sa mga kliyente ng sangay, at kung kailangang mabuhay ang lokal na paglabas sa internet kapag bumagsak ang tunnel.

Sinasagot ng Standard/Unified ang lahat ng tatlo sa parehong paraan: pagmamay-ari ng sentral na firewall ang LAN ng sangay, kasama ang mga tungkulin sa gateway at DHCP, at dumadaan ang trapiko sa tunnel. Pinapanatili ng Standard/Split ang sentral na pamamahala at ipinapadala lamang sa tunnel ang mga naka-configure na network. Hinahayaan ng Transparent/Split ang umiiral na network ng sangay na pangasiwaan ang sarili nitong gateway at address, at ang mga piling trapiko lamang ang inililihis sa tunnel. Tatlong mode, tatlong magkaibang may-ari.

ModeBranch gateway and DHCPTraffic through the tunnel
Standard/UnifiedCentral firewall owns bothAll branch traffic
Standard/SplitCentral firewall owns bothOnly the configured networks
Transparent/SplitThe existing branch router keeps bothOnly the selected flows

Basahin muna ang gitnang hanay, dahil ito ang nagtatakda kung gaano karami sa sangay ang gumagana pa kapag wala ang tunnel.

Sino ang may-ari ng gateway ng sangay at DHCP

Sa pinag-isang kaayusan ay walang sariling gateway ang sangay, na nagpapasimple sa configuration at nagtutuon ng pagpalya sa isang lugar. Maayos ang pagtutuon na iyon kapag maliit ang sangay at may mataas na availability ang sentral na firewall.

Sa transparent na deployment, pinapanatili ng sangay ang sarili nitong router at nakaupo ang RED sa linya upang ilihis ang mga piling trapiko. Pinapanatili nito ang lokal na kontrol at nagdaragdag ng device na ang posisyon sa daan ay mahalaga na ngayon sa bawat inilihis na daloy. Idokumento kung saan ito nakaupo, dahil ang pagbabago sa router ng sangay sa susunod ay maaaring lihim na lumampas dito. Walang kaayusang nananalo sa pangkalahatan; iba-iba ang paghahati nila ng responsibilidad.

Ang pagmamay-ari ng address ang bahaging dapat isulat, dahil ang dalawang DHCP server sa isang segment ay nagdudulot ng paminsan-minsang sira na iniuulat bilang problema sa VPN.

Ano ang nangyayari kapag bumagsak ang tunnel

Ang pagpapatakbo ng Split ay madalas basahin bilang pangakong patuloy na gumagana ang lokal na internet habang may pagpalya ng tunnel, at hindi ligtas ang pagbasang iyon. Nakadepende ang eksaktong pag-uugali sa piniling mode, firmware at device, kaya kabilang ito sa mga pamantayan sa pagtanggap, hindi sa isang palagay.

Magpasya kung ano pa ang dapat gawin ng sangay nang walang tunnel: maabot ang lokal na printer, lutasin ang mga pangalan, tumanggap ng bayad, o wala. Pagkatapos ay sadyang subukan ang kalagayang iyon sa pamamagitan ng pagharang sa tunnel at pagmamasid sa sangay. Ang sangay na tahimik na nawawalan ng DNS ay mas masama kaysa sa malakas na pumapalya, dahil ang tawag sa helpdesk ay dumarating pagkalipas ng mga oras. Isulat ang naobserbahang resulta sa talaan ng disenyo.

Pareho ang sentral na dependency sa lahat ng mode: may dapat magmay-ari ng daan ng pagbawi ng device mismo.

Isulat ang kontrata ng sangay bago mag-deploy

Kasya sa isang pahina ang kontrata ng sangay: mga may-ari, pinagmumulan ng address, mga prefix na dumadaan sa tunnel, patakaran sa paglabas at ang pag-uugaling tinanggap mo kapag may pagpalya.

Pagkatapos ay i-verify ang na-deploy na resulta at hindi ang nilayon. Suriin ang address ng kliyente ng sangay, ang default gateway nito, aling mga prefix ang nalulutas sa tunnel, at ano pa ang sumasagot kapag harang ang tunnel. Ang compatibility, reachability at licensing ay kailangang lahat tiyakin laban sa kasalukuyang dokumentasyon ng vendor para sa eksaktong modelo, dahil hindi ginagarantiya ng pangalan ng produkto ang isang mode. Itago ang pahinang iyon kasama ng rekord ng device upang manahin ng susunod na inhinyero ang mga desisyon at hindi ang diagram.

ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.example

Ulitin ang bloke na iyon na harang ang tunnel, at ang pagkakaiba ng dalawang pagtakbo ay ang pag-uugali kapag may pagpalya na talagang binili mo.

Kaugnay na mga artikulo