Allowlist ng mga VPN endpoint: ang DNS refresh na nakalimutan mo

Ang pag-type ng vpn.example.com sa pagbubukod sa firewall ay parang mag-subscribe sa DNS. Karaniwang nangyayari ang pagsasalin sa oras ng pag-load, pagkatapos ay hinahawakan ng tuntunin ang mga address at walang nagre-refresh sa mga ito. Dalawang bahagi ang naghahati ngayon sa gawain: ang resolver na sumasagot at ang firewall na nag-iimbak. Karamihan sa mga pagkaantala ng endpoint ay nagsisimula kung saan hindi kailanman dinisenyo ang paghahatid na iyon.

Ang hostname sa isang tuntunin ay hindi live na subscription

May mga tool na nagreresolba ng pangalan kapag nag-load ang configuration; may iba na nagtatago ng hostname at muling nagreresolba ayon sa sarili nilang iskedyul; may iba pa na tumatanggap lamang ng mga address. Bihirang sabihin ng nakikitang configuration kung alin. Karaniwang ipinapalagay ng mga halimbawa sa dokumentasyon ang kaso ng pag-load, kaya nagulat ang mga tao sa pagkakaiba sa panahon ng migration. Basahin ang pag-uugali ng implementasyon bago ipagpalagay na mapapansin ang pagbabago ng address, dahil ang lumang allowlist ay mukhang eksaktong katulad ng gumagana hanggang sa lumipat ang endpoint.

Ang tuntuning nagngangalan ng tamang host ay maaari pa ring payagan ang maling address. Ang puwang na iyon ang mito, hindi isang typo.

Ang TTL ng cache ay hindi ang timer ng iyong firewall

May tagal ng buhay ang mga DNS record, at nag-ca-cache ang mga resolver ng mga sagot sa panahong iyon. Ang espesipikasyon ng DNS ay tumutukoy sa pag-uugaling iyon ng cache, ngunit pinamamahalaan nito ang data ng DNS, hindi ang hiwalay na imbakan ng address ng firewall. Ang maikling TTL ay hindi lumilikha ng gawain sa pag-refresh kung wala. Nagaganap din ang caching sa higit sa isang antas, kaya ang sagot na nakikita ng terminal ay maaaring hindi ang nakita ng firewall.

Magtanong ng tatlong bagay sa aktwal na produkto: kailan ito nagreresolba, saan iniimbak ang resulta, at ano ang nag-trigger ng update. Kung ang sagot ay sa boot lamang, ang isang pangmatagalang session ay maaaring mabuhay nang mas mahaba kaysa sa address kung saan ito pinayagan.

dig +short vpn.example.com
resolvectl query vpn.example.com

Idisenyo ang pag-refresh at pagkabigo bilang isang patakaran

Ang pinapanatiliang pagbubukod ay nangangailangan ng malinaw na sagot: ano ang nag-trigger ng refresh bago pumili ng bagong address ang client, paano nagbabago ang pinapayagang set nang hindi nagbubukas ng malawak na pansamantalang window, at kailan tinatanggal ang mga lipas na entry. Isulat ang mga sagot na iyon sa tabi ng tuntunin.

Piliin nang sinasadya ang pag-uugali sa pagkabigo. Ang pagpapanatili ng lumang address ay maaaring magsave ng session at mag-iwan ng lipas na permit; ang paglilinis ng set ay maaaring humadlang sa pagbawi. Ni isa ay hindi dapat maging aksidenteng resulta ng bigong lookup. Isulat ang napiling pag-uugali sa runbook upang ang susunod na operator ay hindi mag-improvise sa ilalim ng presyon.

Panatilihing makitid din ang bootstrap DNS. Ang walang kondisyong pagbubukod para sa pampublikong resolver ay direktang landas ng DNS para sa lahat ng tumutugma, hindi lamang para sa pangalan ng endpoint.

Patunayan ang pagbabago ng endpoint, hindi ang unang koneksyon

Gamitin ang sinusuportahang manager ng client kung nag-uugnay na ito ng resolusyon at pag-block. Sa host na PF na pinamamahalaan ng site, panatilihin ang pagmamay-ari at plano ng pagbawi ng site sa halip na kopyahin ang syntax ng talahanayan ng hostname mula sa ibang platform na may ibang pag-uugali sa lifecycle.

Sa isang aprubado at hindi mapaminsalang pagsubok, ihambing ang address na pinipili ng client sa aktibong pinapayagang set bago at pagkatapos ng kontroladong pagbabago. Saklawin ang bigong lookup, pagtanggal ng entry na hindi na wasto at, kung sinusuportahan, ibang pamilya ng address. Dapat bumangon ang inilaan na tunnel habang ang walang kaugnayang direktang trapiko ay nananatili sa ilalim ng patakaran. Ang matagumpay na unang koneksyon ay nagpapatunay lamang na ang paunang pagsasalin ay nagkataong tama.