Ano ang itatala para sa VPN na site-to-site: mga selector at saklaw

Anim na buwan matapos mailagay ang isang tunel, tumigil nang tumugma ang isang bagong subnet sa patakaran at ang tanging dokumento sa share ay nagsasabing VPN ng opisina. Iyan ang pagkabigo na pinipigilan ng talaan ng selector, at ito ay tiyak: nagbago ang isang set ng address samantalang hindi nagbago ang mga papeles. Ang wastong pagsulat ng talaan ay nangangahulugang alam mo kung alin sa ilang set ng address ang inilalarawan mo, at itinatala mo ang aktuwal na ipinapatupad ng kabilang panig, hindi ang in-configure mo.

Ang naka-configure ay hindi napagkasunduan

Sa isang IPsec tunnel na batay sa patakaran, bawat panig ay nagmumungkahi ng mga selector ng trapiko: mga saklaw ng pinagmulan at patutunguhan para sa child association. Maaaring paliitin ng panig na tumutugon ang panukalang iyon, kaya ang na-install na asosasyon ay maaaring mas mababa ang saklaw kaysa nakalista sa configuration. Ang talaang kumokopya ng configuration ay naglalarawan ng layunin, hindi ng kasalukuyang saklaw ng proteksyon. Tahimik na naghihiwalay ang dalawa, at walang anumang bagay sa pahina ng estado ng tunel ang nagtuturo nito.

Panatilihin ang dalawang hanay, kasama ang petsang naobserbahan mo. Ang naka-configure na selector ay ang sinadya mo; ang napagkasunduan ay ang ipinapatupad ng kernel ngayon. Kapag nagkaiba sila, mas madalas na ipinapaliwanag ng pagkakaibang iyon ang isang nakakagulat na pagkabigo kaysa sa isang bug sa routing.

Ang isang asosasyon ay hindi rin kumakatawan sa bawat naka-configure na pares. Ang isang tunel na may ilang kombinasyon ng selector ay maaaring magtapos na may ilang child association, at ang talaang naglilista ng isa sa kanila ay bahagyang imbentaryo. Isa-isahin sila sa halip na ibuod.

Iba ang pagpili ng mga tunel na batay sa ruta

Sa isang interface na batay sa ruta, ang routing table ang nagpapasya kung ano ang pumapasok sa tunel at ang mga selector ay maaaring sadyang malawak. Ito ay lehitimong disenyo at hindi kapabayaan, at dapat itong ilarawan ng talaan nang ganoon. Isulat ang ruta, ang interface na tinutukoy nito, at ang patakaran ng firewall na naglilimita kung aling mga serbisyo ang maaabot. Ang saklaw ng proteksyon ay sadyang malawak, at ang saklaw ng serbisyo ang gumagawa ng pagpapaliit.

Ang pagkopya ng template na batay sa patakaran sa isang tunel na batay sa ruta ay gumagawa ng dokumentong naglalarawan ng mekanismong hindi ginagamit ng deployment. Hahanapin ng susunod na inhinyero ang mga selectorna hindi dapat naroon, at maghihinuha na mali ang configuration ng tunel gayong mahina lamang ang dokumentasyon nito.

Ang pagsasalin ay kabilang sa parehong talahanayan

Kapag nagpapakita ang NAT ng ibang saklaw sa kabilang panig, itala ang orihinal at isinaling mga prefix nang magkasama. Itala ang yugto kung saan tumutugma ang mga selector at patakaran ng access sa kanila, dahil ang pagkakasunod-sunod ang nagpapasya kung makikita man ng malayong panig ang address na isinulat mo. Ang talahanayang may isa lamang sa dalawang saklaw ay mas masahol pa sa walang talahanayan, dahil mukhang kumpleto ito.

Ito ang detalyeng sumisira sa gumaganang tunel pagkatapos ng pagbabago sa NAT: tumutugma pa rin ang selector sa orihinal na prefix, natatanggap na ng kabilang panig ang isinalin, at ang ruta ng pagbabalik nito ay tumuturo sa address na wala nang umiiral. Walang naglo-log ng error sa sandaling tumigil na silang magtugma.

Ang pribadong DNS ay kabilang sa parehong lugar. Ang pangalang niresolba sa address na hindi magagamit mula sa kaugnay na site ay error sa dokumentasyon na may kalakip na support ticket, at ang tunel ang sisisihin.

Ilakip ang pangangailangan sa serbisyo

Ang protektadong saklaw ay hindi listahan ng pahintulot. Isulat kung aling mga serbisyo ang dapat maabot mula sa aling pinagmulan, at kung sino ang nagmamay-ari ng application sa likod nila. Ang dalawang field na iyon ay sumasagot sa magkaibang tanong, at ang paghahalo sa kanila ang dahilan kung bakit nauuwi ang pagsusuri ng seguridad sa pagtatalo tungkol sa routing kaysa sa access.

Pagkatapos, pangalanan ang administrador ng network na nagpapanatili ng patakaran. Ang imbentaryo ng selector na walang may-ari ay tahimik na naluluma, at ang naluma ay hindi makikilala sa mali kapag nasira ang tunel sa alas-dos ng madaling-araw. Ang may-ari rin ang taong makakapagpatunay na ang pagbabago ay sinadya.

Gawing plano ng pagsubok ang talaan

Para sa bawat kinakailangang landas, pumili ng representatibong host ng pinagmulan at patutunguhan at itala ang inaasahang ruta, serbisyo at gateway ng tugon. Ginagawa nitong plano ng pagsubok ang dokumento kaysa paglalarawan. Basahin pabalik ang aktibong asosasyon gamit ang utos sa ibaba, at ihambing ito sa napagkasunduang hilera na isinulat mo.

swanctl --list-sas

Ang balangkas na limang linya ay karaniwang sapat upang manatiling tapat ang talaan. Ang bersyon sa ibaba ay kasya sa isang ticket ng pagbabago nang walang putol:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Ang ping lamang hanggang sa gateway ay hindi ang pagsubok ng pagtanggap. Hindi nito ginagamit kailanman ang landas ng transit, kaya maaari itong pumasa habang bawat dinadaan na daloy ay nabibigo. Subukan mula sa host sa isang panig hanggang sa serbisyo sa kabila at tiyakin na dumarating ang tugon sa pamamagitan ng tunel. Kung ping lamang ang pumasa, natagpuan na ng talaan ang problema sa forwarding na dapat nitong pigilan. Ipinaliwanag ng dokumentasyon ng strongSwan tungkol sa forwarding kung paano nag-iinteract ang mga selector, ruta at forwarding sa isang Linux peer.