Mga static na address ng tunnel sa pfSense: preference o reservation?

Dalawang disenyo ang magkamukha sa papel at ibang-iba ang kilos kapag may rule na umaasa sa kanila. Ang isa ay nagta-type ng address sa client override at nagtitiwala sa address bilang pagkakakilanlan. Ang isa naman ay ganap na nagsasara ng dynamic na pagtanggap, kaya ang isang endpoint ay may natatanging pagtatalaga o hindi kumokonekta. Ang pangalawa lamang ang gumagawa sa address na isang policy input na kayang ipagtanggol, at sulit na unawain ang pagkakaiba bago magsulat ng kahit isang firewall rule.

Ano ba talaga ang ipinapangako ng override address

Ang client-specific override ay may mga opsyon bawat kliyente, kasama ang ginustong address ng tunnel. Inilalarawan ng Netgate ang address na iyon bilang preference at hindi reservation, ibig sabihin ay hindi ibinibigay ng dynamic pool ang address sa iba.

Karaniwan ay maayos iyon. Bihira ang banggaan, at karaniwang nakukuha ng kliyente ang hiniling nito, sapat para sa kaginhawahan at hindi sapat para sa awtorisasyon. Magkaibang pangangailangan ang kaginhawahan at awtorisasyon, at isa lamang sa kanila ang nakakaligtas sa banggaan.

Sa subnet topology, kinukuha ng field ang address ng kliyente kasama ang mask ng network ng server, kaya ang address sa loob ng 10.90.0.0/24 tunnel ay isinusulat bilang 10.90.0.10/24.

Wala sa mga iyon ang nagrereserba ng numero. Ang kliyenteng hindi tumutugma ang override, o ang doble ang session, ay maaaring mapunta sa ibang bahagi ng pool, at ang rule na nakabatay sa address ay naglalarawan noon ng taong wala roon.

Isara ang dynamic na landas gamit ang may saklaw na default

Ang alternatibo ay server na static lamang: bawat tinatanggap na endpoint ay may sariling pagkakakilanlan at sariling natatanging address, at walang ibang pumapasok.

Ang pagpapatupad nito ay nangangahulugan ng DEFAULT override na nakasaklaw sa isang server na iyon lamang na may naka-enable na pagharang sa koneksyon. Ang kliyenteng walang tugmang override ay hindi na makakabalik sa ordinaryong dynamic na pagtanggap. Ang nag-iisang linyang iyon ang gumagawa sa preference na isang saradong set.

Mahalaga ang saklaw. Ang default override na inilapat sa bawat VPN instance sa device ay mag-lock ng mga walang kaugnayang tunnel, at ang pagpalya na iyon ay mukhang sirang serbisyo kaysa desisyong pampatakaran. Ikabit ito sa nag-iisang server na binabago mo ang modelo ng pagtanggap. Pagkatapos ay itala ang saklaw sa change record, dahil hindi maaalala ng susunod na tao kung aling tunnel ito nabibilang.

Pagkatapos ay i-audit ang buong pinapayagang set. Hindi inaayos ng default block ang isang pinangalanang override na naiwan nang walang address, at ang endpoint na iyon ay basta mabibigo kumonekta nang walang malinaw na palatandaan kung bakit.

Itugma sa pagkakakilanlang talagang ginagamit ng server

May itinatapat ang override. Sa server na nagtapatapat ng common name ng mga certificate, ang pangalan ng override ay dapat ang common name na iyon, hindi ang display name ng tao. Kopyahin ito mula sa certificate at hindi mula sa listahan ng account.

Ang server na naka-configure na gamitin ang username bilang common name ay tumatapat sa ibang susi, at ang override na pinangalanan ayon sa certificate ay hindi kailanman gagana. Basahin ang setting sa halip na hulaan mula sa ipinapakita ng listahan ng account.

Panatilihin ang mga karagdagang salik ng pagpapatunay na kailangan ng deployment. Binabago ng saradong modelo ng address kung sino ang makakonekta at anong address ang matatanggap; hindi nito pinapalitan ang pagsusuri ng certificate o ang ikalawang salik.

Isulat ang mga rule ng pag-access kapag maayos na ang mapa

Kapag sarado na ang mapa ng pagkakakilanlan sa address, makakatukoy na ang mga rule sa address nang hindi nagpapanggap na tao ang mga ito. Ang alias na nagpapangkat ng mga endpoint ng isang tao ay makakaabot sa isang partikular na serbisyo habang ang ibang alias ay umaabot sa iba. Nagiging bagay na masusuri ang alias, at nagiging detalye ng implementasyon sa loob nito ang address.

Panatilihing malinaw ang mga destinasyon at port. Ang pagpayag sa buong lokal na network mula sa buong tunnel pool ay siya mismong disenyong dapat palitan ng pagsasanay na ito.

Basahin ang floating, group at interface rules sa totoong pagkakasunod-sunod ng pagsusuri, dahil ang naunang malawak na pagdaan ay tumatalo sa kasunod na makitid. Ang pagpatay sa panloob na pagpapasa mula kliyente hanggang kliyente ay nagpapanatili sa trapiko ng magkakasama sa hangganan kung saan sinusuri ang mga rule na iyon. Ang rule na umiiral lamang sa papel ay hindi pagpapatupad.

Subukan ang mga negatibong kaso

Subukan ang apat na bagong koneksyon: pinangalanang endpoint, isang walang anumang override, serbisyong dapat maabot, at serbisyong hindi dapat. Ang endpoint na wala sa listahan ang mahalagang kaso, dahil iyon ang pinaglalaanan ng disenyo upang pigilan. Kung kumokonekta ito, hindi ginagawa ng default block ang trabaho nito.

Suriin ang IPv6 nang hiwalay, dahil walang sinasabi ang patakaran sa address na IPv4 tungkol sa pangalawang stack. Pagkatapos ay tiyakin na awtorisado pa rin ng application ang user, dahil ang address ng tunnel ay katotohanan ng network at hindi patunay kung sino ang nasa keyboard. Kapwa kabilang sa acceptance note ang dalawang pagsusuri.

Sa huli, planuhin ang migration. Ang mga bagong override at makitid na rule ay hindi nagbabago nang paurong sa mga session na naitatag na, kaya ang mga umiiral na estado ay dapat mag-expire o sadyang linisin.