Bakit nabibigo ang pagkopya ng config ng OpenVPN server sa isang sangay

Ang pagkopya ng gumaganang config ng server, pagpapalit ng ilang address at pagtawag dito na profile ng sangay ay karaniwang gumagawa ng koneksyon. Iyon ang pinakamasamang resulta, dahil tumatakbo ang sangay sa maling papel, naglalantad ng materyal na hindi dapat lumabas sa hub, at nag-iiwan ng asosasyon ng ruta na walang naaalalang gumawa. Itinatago ng koneksyon ang tatlong problema nang sabay, at umaangat ang tunnel bago pa ito suriin ng kahit sino.

Ang pagtingin sa sangay bilang kapareha na may sariling pagkakakilanlan at papel sa network ang gumagawa ng profile na tama. Ang pagwawasto ay hindi mas magandang kopya, at ang natitirang bahagi ng pahinang ito ay tungkol sa dapat hawakan ng isang kliyente.

Dalawang papel na mukhang isang file

Sa TLS mode may komplementaryong gawain ang dalawang panig. Nakikinig ang isang panig, may hawak ng sertipiko at susi ng server at nagpapasya kung sinong kliyente ang makakakonekta. Nagsisimula ang kabilang panig, bineberipika ang tagapakinig at ipinapakita ang sariling pagkakakilanlan.

May mga direktiba sa file ng server na walang saysay sa kliyente: address ng pagkakabit at port na pakikinggan, pool ng address na ipapamahagi at madalas listahan ng pagtulak para sa mga setting na dapat matanggap ng mga kliyente. Ang pagkopya ng mga iyon sa sangay ay gumagawa ng device na sinusubukang maging tagapakinig at kliyente nang sabay.

Ang pribadong susi ang pinakamahalagang bahagi. Hindi dapat kailanman dalhin ng kliyente ang pribadong susi ng server, at hindi rin nito kailangan ang susi ng pagpirma ng CA. Ang sertipiko ng CA ay pampublikong materyal ng pagtitiwala; ang susi ng pagpirma ay pag-aari ng lugar kung saan inilalabas ang mga sertipiko.

Ano ang dapat taglayin ng profile ng sangay

Kailangan ng profile ng sangay ang malayong endpoint at transport, ang pinagkakatiwalaang pagkakakilanlan ng server, ang sariling sertipiko at susi ng sangay, at ang mga ruta at setting ng DNS na talagang kailangan ng sangay. Wala nang ibang sapilitan.

Panatilihing hiwalay ang pagkakakilanlan ng sangay sa bawat site. Dalawang sangay na nagsasalo ng isang sertipiko ay nangangahulugang ang pagbawi sa isa ay nagpapahina sa isa, at hindi sila kayang paghiwalayin ng mga log ng hub. Ang pagkakakilanlan sa bawat site ang nagpapagana sa bakas ng audit at sa kuwento ng pagbawi.

Mag-ingat sa mga workflow ng appliance. Ang Client Export package ng pfSense ay gumagawa ng profile para sa mga karapat-dapat na konteksto ng Remote Access, at ang listahan ng server nito ay may lamang mga server na naka-configure sa isang Remote Access mode. Ang server na site-to-site ng ibang mode ay hindi lumilitaw, at ang kawalan na iyon ay impormasyon, hindi paanyaya na kopyahin ang mga lihim ng server.

Kung hindi ine-export ng appliance ang profile na kailangan mo, gamitin ang dokumentadong workflow ng kliyente na site-to-site o buuin ang profile mula sa sinusuportahang halimbawa ng naka-install na release. Mag-export ng backup ng server sa sangay lamang kung ang plano ay ibalik ang isang server, na hindi naman. Nagdadala rin ang backup ng pribadong materyal ng hub, kaya ang paglipat nito sa isang sangay ay desisyon sa paghawak ng susi, hindi paglilipat ng file. Panatilihin ito sa hub at buuin ang pagkakakilanlan ng kliyente kung saan inilalabas ang mga sertipiko.

Hiwalay ang asosasyon ng kapareha sa network

Ang kliyente ng sangay na matagumpay na nakakonekta ay hindi pa rin makakapagpadala ng traffic para sa LAN nito hangga't hindi alam ng hub na pag-aari ng kaparehang ito ang prefix na iyon. Ang asosasyong iyon ay nasa hub, nakatali sa pagkakakilanlan ng kliyente, at hiwalay sa sariling ruta ng sangay patungo sa malalayong network. Kung wala ito, lumilitaw na maabot ang mga host ng sangay sa estadistika ng tunnel at hindi naman sa praktika. Ang log ng hub ang lugar kung saan kino-confirm kung naipatupad ang asosasyon.

Ang pagdaragdag ng ruta sa operating system ng hub ay hindi kapareho ng pagsasabi sa OpenVPN kung sinong kliyente ang may-ari ng prefix. Kung walang asosasyon sa bawat kliyente, umaabot ang packet sa interface ng tunnel at itinatapon dahil walang kaparehang nag-aangkin ng destinasyon.

Sa panig ng sangay, ang katumbas na pangangailangan ay ruta patungo sa mga network na dapat abutin, kasama ang router ng LAN na marunong magbalik ng traffic sa sangay. Magkaibang bagay ang pagmamay-ari sa panig ng server at ang mga rutang destinasyon sa panig ng kliyente, at ang gumaganang tunnel ay nagpapatunay lamang ng unang pagtalon. Isulat ang dalawa sa mga tala ng pagturn-over ng sangay, dahil isa lamang ang mahahanap ng susunod na inhinyero.

Ang patunayan na ang sangay ang kaparehang iniisip mo

Beripikahin ang pagkakakilanlan bago beripikahin ang traffic. Dapat ipakita ng log ng hub ang karaniwang pangalan ng sertipiko ng sangay, at ang address na natanggap ng kliyente ay dapat tugma sa pool o fixed assignment na nilayon mo. Kung ibang pangalan ang ipinapakita ng log, may dalang pagkakakilanlan ng iba ang profile.

Pagkatapos, beripikahin ang asosasyon sa pamamagitan ng pagpapadala ng isang kahilingan mula sa host ng sangay patungo sa resource sa panig ng hub at kumpirmahing nagtagumpay ito gamit ang inaasahang source address. Subukan ang destinasyong hindi dapat maabot ng sangay at kumpirmahing nabibigo ito, dahil ang mapagpahintulot na rutang nagkataong gumagana ay hindi kapareho ng tamang patakaran.

Sa huli, bawiin ang pagkakakilanlan ng sangay at kumpirmahing nabibigo ang koneksyon habang patuloy na gumagana ang sertipiko ng hub at ang iba pang site. Kung sinisira ng pagbawi ang hub, may pinagsaluhan ang mga papel at pagkakakilanlan, at iyon ang natuklasang sulit iulat pabalik sa disenyo.

Ang tapos na sangay ay may dokumentadong pagkakakilanlan, profile para sa kliyente lamang, asosasyon ng kapareha at network sa hub at nasubok na daan pabalik. Ang pagbaliktad ng teksto sa file ng server ay wala kang ibinibigay sa mga iyon.