Maaari bang magsilbi ang isang WAN interface sa VPN sa pagitan ng mga site at remote access?

Ang isang pampublikong address ay maaaring magsilbi nang sabay sa isang branch tunnel at isang pool ng mga gumagalaang user. Ngunit hindi ito makapaglilingkod sa isang pinagsasaluhang tuntunin ng pagtanggap. Magkaiba ang peer ng sangay at ang gumagalaang user sa kung sino ang sinasabi nilang sila, kung paano sinusuri ang patunay na iyon, kung anong mga address ang natatanggap nila at kung aling mga prefix ang maaaring sumagot sa kanila. Kapag itinuring na ninyong detalye ng transportasyon ang panlabas na address at hindi pagkakakilanlan, nagiging mas simple ang disenyo.

Mabilis na pagsubok ng sentido komun: subukang isulat ang dalawang rekord ng pagtanggap bago hawakan ang router. Kung isang kundisyon ng pagtutugma lang ang kailangang sumaklaw sa dalawa, malabo na ang patakaran, at ang unang sintomas ay magmumukhang sira ng routing o firewall bagaman sira ng pagkakakilanlan talaga ito.

Dalawang rekord bago ang anumang konfigurasyon

Maikli at matatag ang rekord ng sangay. Inililista nito ang address ng peer o pangalan ng certificate, ang paunang ibinahaging key o trustpoint ng certificate, ang mga protektadong subnet sa magkabilang panig, ang tunnel interface, at ang static na ruta na nagpapadala ng trapikong patungo sa sangay papasok sa tunnel na iyon. Bawat field ay tungkol sa isang kilalang peer at isang takdang hanay ng mga prefix.

Mas malawak at mas personal ang rekord ng paggala. Inililista nito ang protocol at port ng client, kung paano nagpapatunay ng pagkakakilanlan ang isang user o device, ang pool ng address na ibinibigay sa pagkonekta, ang mga resource na maaaring abutin ng pool na iyon, ang mga prefix ng split tunnel, ang mga DNS server na itinutulak sa client, at anumang ikalawang salik. Bawat field ay sumasagot sa tanong tungkol sa hindi alam na bilang ng mga user at hindi tungkol sa isang gateway.

Ang pagkakaibang iyon sa detalye ang buong dahilan kung bakit naghihiwalay ang dalawang papel. Ang profile ng sangay ay maaaring magtiwala nang ligtas sa isang key dahil ang key ay pag-aari ng isang device sa isang lugar. Ang profile ng paggala na nagtitiwala sa isang group key para sa lahat ay gumuguho sa pananagutan ng bawat user, at kadalasan ay natutuklasan iyon mamaya, sa pagsusuri ng insidente at hindi sa paglulunsad.

Saan naghihiwalay ang pagtutugma ng peer at authentication

Sa IOS XE, dinadala ng IKEv2 profile ang mga parameter na hindi maaaring pag-usapan at ang mga kundisyon na ginagamit sa pagpili ng peer. Ibig sabihin, ang panig ng sangay at ang panig ng paggala ay kailangan ng kani-kanilang profile, kahit nagtatapos sila sa parehong interface at kahit pinagsasaluhan nila ang isang cryptographic PKI. Idinodokumento ng Cisco ang mga papel ng profile, authentication at pagtutugma sa kanilang gabay sa konfigurasyon ng IKEv2 para sa IOS XE 17.

Karaniwang itinutugma ng profile ng sangay ang makitid na pagkakakilanlan: isang malayong address, isang FQDN o isang subject ng certificate. Ang isang bagay na tulad ng match identity remote address 198.51.100.10 255.255.255.255 ay nagpapako ng isang peer, at ang authentication remote pre-share na may key na itinatago bawat site ay sapat na. Panatilihing kasing-espesipiko ng pinapayagan ng listahan ng peer ang pagtutugma, dahil ang isang wildcard na nagsasapawan na mas mataas sa pagkakasunod-sunod ng pagpili ay maaaring humila sa trapiko ng sangay papasok sa maling profile.

Hindi kayang magpako ng address ang profile ng paggala, kaya itinutugma nito ang isang grupo, isang key-id o isang field ng certificate, at pagkatapos ay ipinapasa ang tunay na pagsusuri ng user sa AAA o sa patakaran ng awtorisasyon na nakakabit sa profile. Mahalaga ang paghahiwang iyon: sinasagot ng authentication ng peer kung pinapayagan ang client na bumuo ng tunnel, at sinasagot ng awtorisasyon bawat user kung aling pool at aling mga resource ang nakukuha niya. Ang paggamit ng key ng sangay bilang pangkalahatang login ay itinatapon ang ikalawang sagot.

Kailangan din ng pagpapasa at pagsasalin ang parehong paghahiwang

Magkaibang problema ang pagtanggap at maabot. Pinatutunayan ng matagumpay na palitan ng IKE at IPsec na nagkakasundo ang mga panig sa mga key; hindi ito gumagawa ng ruta patungo sa pool na natanggap ng client. Kaya kailangan ng mga pool ng malayong access ng daan pabalik: alinman sa static na rutang tumuturo sa tunnel interface o isang routing protocol na naglalagay ng buod ng pool. Karaniwang dumarating ang mga prefix ng sangay sa parehong proseso ng routing na nagsisilbi sa nalalabing bahagi ng site.

Ang pagsasalin ang lugar kung saan pinakamadalas banggain ang dalawang papel. Ang trapikong nasa pagitan ng mga site na dapat magpanatili ng pribadong address nito ay kailangan ng pagbubukod sa NAT na limitado sa dalawang prefix na iyon, sa dalawang direksyon. Karaniwang kailangan din ng mga gumagalaang client ng pagbubukod para sa kanilang trapiko sa tunnel, ngunit ang trapiko nila patungo sa internet ay lumalampas sa tunnel sa pamamagitan ng split tunnel o lumalabas sa hub pagkatapos ng NAT. Ang pagbubukod sa lahat ng dumarating mula sa tunnel ay ang klasikong pagkakamali, dahil inaalis din nito ang pagsasalin sa trapikong talagang nangangailangan nito.

Panatilihing kasingkitid ng mga tuntunin ng pagtanggap ang mga tuntunin ng pagbubukod. Kung magsasapawan ang buod ng pool at ang prefix ng sangay, nagiging malabo ang daan pabalik bago pa man maitalon ang anumang packet, at ang sintomas ay lumilitaw na isang site na paminsan-minsang nawawalan ng subnet at hindi bilang malinis na pagkasira ng tunnel.

Mga kaso ng pagtanggap na naglalantad ng krus na patakaran

Bumuo ng apat na kaso at patakbuhin sila sa pagkakasunod-sunod. Naabot ng isang host sa sangay ang resource na para sa sangay lamang. Naabot ng gumagalaang client ang parehong resource sa pamamagitan ng address ng pool nito. Sinusubukan ng gumagalaang client ang isang prefix ng sangay na hindi dapat hawakan. Sinusubukan ng peer ng sangay na kumuha ng address mula sa pool ng malayong access. Ang huling dalawa ang humuhuli sa pinagsasaluhang profile, dahil tahimik silang nabibigo sa normal na pagsubaybay.

Pagkatapos ay tiyakin ang data plane at hindi ang konfigurasyon. Sinasabi ng show crypto ikev2 sa at show crypto ipsec sa kung aling profile at aling mga selector ang nagdala ng bawat daloy, samantalang ipinapakita ng show ip nat translations at ng mga counter ng tunnel kung talagang nagtugma ang daan pabalik at ang pagbubukod. Isinasara ng isang tracer o paghuli ng packet sa tunnel interface ang loop.

Isulat ang naobserbahang pagkakakilanlan, ang address ng pool at ang napiling patakaran sa tabi ng bawat resulta. Tapos na ang pagtakbo kapag bawat kaso ay tumutugma sa eksaktong isang rekord, at walang kaso ang nangangailangan ng pansamantalang pagbubukod upang pumasa.