Mga static na address ng kliyenteng OpenVPN sa likod ng OPNsense

Kailangan ng mga pangalan ang mga address na hindi gumagalaw, at ginagawang malagkit lang ng pool file ng OpenVPN ang isang address. Mawala ang file na iyon, o muling mag-isyu ng certificate sa ilalim ng ibang common name, at mapupunta ang bumabalik na kliyente sa ibang bahagi ng pool habang ang DNS record nito ay nakaturo pa rin sa lumang address. Ang matibay na sagot ay isang override na partikular sa kliyente na nagpi-pin ng address, kasama ang mas malawak na tunnel network upang ang mga naka-pin na address ay nasa labas ng dynamic na saklaw. Ang aritmetika sa likod ng pagpapalawak na iyon ang tinitirhan ng karamihan ng kalituhan.

Inihahawak ng OPNsense ang mga override na iyon sa mga setting na partikular sa kliyente ng server, naka-key sa common name ng certificate, na ginagawang bahagi ng address plan ang common name.

Ang malagkit na lease ay hindi static na address

Isinusulat ng pool file ang mga mapping ng address sa kliyente at ibinabalik ang mga ito kapag muling kumonekta ang isang kilalang kliyente. Iyon ay kaginhawahan, hindi kontrata: maaaring muling likhain ang file, nawawala ang mapping kapag nagbago ang pagkakakilanlan ng kliyente, at hindi magkakasundo ang dalawang server na nagbabahagi ng pool. Gumagana nang iba ang override na partikular sa kliyente, dahil nagmumula ang address sa configuration at hindi sa kasaysayan. Nakakaligtas din ito sa restart at reinstall ng appliance, basta't naka-backup ang override kasama ng iba pang configuration.

Gumagana ang dynamic na alternatibo, ang pag-uugnay ng VPN sa DNS gamit ang client-connect script at mga dynamic na update, at nangangailangan ito ng resolver na tumatanggap ng mga update at script sa bawat koneksyon. Sa isang appliance, limitado ka sa mga package na ipinapadala ng vendor, at doon karaniwang humihinto ang planong iyon.

Ang /30 na aritmetika na walang nag-eenjoy

Sa ilalim ng default na net30 topology, bawat kliyente ay may sariling /30: ang unang magagamit na address ay napupunta sa panig ng server, ang pangalawa sa kliyente. Kaya dapat nasa labas ng dynamic na tunnel network ng server ang mga override, na nangangahulugang kailangan munang palawakin ang network na iyon. Ang server sa 10.8.0.0/24 ay maaaring lumipat sa 10.8.0.0/23, na iniiwan ang kalahati ng lumang saklaw para sa mga dynamic na kliyente at ang kabilang kalahati para sa mga override. Idagdag ang orihinal na /24 bilang karagdagang lokal na IPv4 network upang ang trapiko sa dalawang kalahati ay pumasok sa tunnel.

Ang bawat override address ay dapat mahulog sa hangganan ng /30, kaya ang huling octet ay multiple ng apat. Ang /30 sa 10.8.1.0 ay nagbibigay sa kliyente ng 10.8.1.2, at iyon ang address na dala ng DNS record. Ang pagpili ng 10.8.1.3 sa halip ay gumagawa ng kliyenteng kumokonekta at hindi makakapagpadala ng trapiko, dahil ang address ay kabilang sa subnet na hindi kailanman itinalaga ng topology sa kanya.

Mas madaling panatilihin ang plano kung ang mga override ay ilalaan mula sa itaas ng pinalawak na saklaw pababa, upang lumawak ang dynamic na pool sa bakanteng espasyo sa halip na umikot sa mga fixed island.

Mga lokal na network at ang zone na tinatanong ng mga kliyente

Ang trapiko mula kliyente hanggang kliyente ay nangangailangan ng sariling pahintulot. Dapat isama ng listahan ng lokal na IPv4 network ng server ang dalawang kalahati ng saklaw, dynamic at static; kung wala ito, tumatanggap ang server ng packet mula sa isang kliyente at walang patakarang magpapadaan nito sa isa pa. Ang sintomas ay parang pagkabigo ng DNS, dahil nagre-resolve ang pangalan at nabibigo pa rin ang koneksyon. Suriin din ang setting ng kliyente-sa-kliyente, dahil ang entry ng lokal na network lamang ay hindi nagpapagana ng pagpapasa sa pagitan ng mga peer.

I-publish ang mga record sa zone na aktwal na tinatanong ng mga remote na kliyente. Ang isang record sa zone na pinaglilingkuran lamang ng LAN resolver ay hindi nakikita ng kliyenteng ang naka-push na resolver ay nakaturo sa ibang lugar, at ang pagdaragdag ng mas maraming record sa maling zone ay hindi kailanman nag-aayos nito. Kumpirmahin ang naka-push na DNS option at ang search domain bago magdagdag ng kahit ano.

Ano ang dapat i-check sa bagong koneksyon

Muling ikonekta ang kliyente at kumpirmahin na tumutugma ang itinalagang address sa override nito bago subukan ang anupaman. Pagkatapos ay i-resolve ang pangalan mula sa pangalawang kliyente at kumonekta sa serbisyo sa pamamagitan ng pangalan, na sumusubok nang sabay sa DNS record, ruta at firewall. Kumpirmahin ang path ng sagot sa panig ng server, dahil ang pangalang nagre-resolve habang hindi maabot ang serbisyo ay problema sa routing o patakaran, hindi sa pagpapangalan. Itago ang talahanayan ng override sa tabi ng listahan ng certificate upang sabay na masuri ang dalawa.

Ang certificate na muling inisyu sa ilalim ng ibang common name ay hindi na tumutugma sa override nito at ibinabalik ang kliyente sa dynamic na pool. Asahan iyon pagkatapos ng anumang pagbabago ng pagkakakilanlan.