Bakit hindi naaabot ng mga kliyente ng OpenVPN ang mga IPsec selector ng gateway

Mag-ping mula sa gateway patungo sa host sa likod ng malayong IPsec tunnel at malinis itong sumasagot, kaya mukhang malusog ang tunnel at tuloy ang ticket. Pagkatapos sinubukan ng konektadong kliyente ang parehong host at walang bumalik. Ang ping na iyon ay hindi kailanman naging ebidensya para sa daloy ng kliyente, dahil lumabas ito gamit ang sariling source address ng gateway at tumugma sa ibang IPsec selector. Ang pag-unawa kung bakit nagkakaiba ang dalawang kaso ang malaking bahagi ng pagtatama.

Ang ping ng gateway ay sumusubok ng daloy na hindi ginagamit ng iyong kliyente

Ang source address ang nagpapasya kung aling patakaran ang nalalapat. Ang packet na nilikha sa gateway ay lumalabas na may address mula sa lokal nitong LAN o mula sa dulo ng tunnel, at ang patakarang tumutugma rito ay isinulat para sa eksaktong kasong iyon. Ang packet ng kliyente ay dumarating sa interface ng OpenVPN na may address mula sa pool ng kliyente, na isang ganap na ibang selector.

Kaya ang kabiguan ay mukhang problema sa pagruruta gayong talagang problema ito sa saklaw ng patakaran. Ang maabot mula sa gateway ay nagpapatunay na buhay ang peer at napagkasunduan ang mga panukala, at wala itong pinatutunayan tungkol sa kung protektado ang pool.

Itulak ang malayong prefix na talagang kailangan ng aplikasyon

Kunin ang halimbawang pares 10.8.0.0/24 para sa mga konektadong kliyente at 172.30.239.0/25 para sa protektadong malayong network. Ang kailangan ng kliyente ay ruta patungo sa pangalawang prefix, hindi sa LAN ng gateway at hindi sa ibang address ng tunnel. Ang rutang itinulak sa pool ang dahilan kung bakit ipinapasa ng kliyente ang trapik na iyon sa gateway. Kung wala ito, hindi kailanman maabot ng packet ang desisyon sa patakarang ini-debug mo.

Sa isang Community server na tumatanggap ng itinulak na ruta, kinukuha ng direktiba ang tunay na mask: push "route 172.30.239.0 255.255.255.128". Ang Access Server ay nagko-configure ng parehong destinasyon sa pamamagitan ng mga setting ng pribadong network o patakaran sa pag-access ng naka-install na bersyon, na sadyang pinipili ang routed o translated mode. Ang pag-edit ng mga nabuong firewall chain sa halip na ang pagmamay-aring configuration ang paraan kung paano nagiging imposibleng kopyahin ang gumaganang setup.

Pagkatapos kumonekta, basahin ang routing table ng kliyente at hindi ang intensyon ng server. Ang rutang sumasakop lamang sa pool ay nangangahulugang hindi kailanman dumating ang pagtulak, at ang default na ruta sa tunnel ay mas malawak kaysa sa pangangailangang ito at mabibigla ka mamaya. Suriin ang mask at ang prefix, dahil ang /25 na itinulak bilang /24 ay nagpapadala ng trapik ng kalapit na address sa landas na hindi kayang dalhin ito. Pagkatapos ay tiyakin na pinili ng kliyente ang interface ng tunnel para sa destinasyong iyon.

Isama ang pool ng kliyente sa mga selector

Para sa routed access na nagpapanatili ng mga address ng kliyente, kailangang protektahan ng patakaran ng IPsec ang trapik sa pagitan ng pool at ng malayong prefix. Ang mga selector na isinulat para sa sariling LAN ng gateway ay tumatanggap ng ping at itinatapon ang kahilingan ng kliyente, at iyon mismo ang kawalan ng simetrya na nagpasimula ng pagsisiyasat na ito.

Suriin ang napagkasunduang patakaran at ang mga naka-configure na panukala, halimbawa gamit ang ipsec statusall sa strongSwan o ang katumbas na status command para sa iyong implementasyon. Sa IPsec na nakabatay sa patakaran, ang ordinaryong ruta ay maaaring tumuro sa pisikal na interface habang ang tumutugmang trapik ay naka-encrypt pa rin, kaya walang pinatutunayan ang kawalan ng tunnel device. Ihambing ang mga pares ng selector sa pool at prefix na isinulat mo.

Ang generic na source NAT sa gateway ay makakasira rin ng pagtutugma. Kung ang masquerade rule ay nagsusulat muli ng source ng kliyente bago ang pagsusuri ng patakaran, hindi na mukhang ang selector na isinulat mo ang packet. Isa ito sa mga dahilan kung bakit ang malawak na masquerade rule ay mahinang pagtatama para sa pangalawang VPN: binabago nito kung aling patakaran ang nalalapat at kung aling address ang itinatala ng malayong panig. Ibukod ang trapik na balak mong iruta, o sadyang isalin ito at i-update ang mga selector.

Sadyang pumili ng pagruruta o pagsasalin

Ang pagruruta ay nagpapanatili sa address ng kliyente na nakikita ng malayong panig, kaya nananatiling makabuluhan ang mga malayong log at patakaran bawat source, at kailangang malaman ng malayong gateway ang pabalik na landas sa pool. Ang pagsasalin ay nagtatago ng pool sa likod ng isang address, na nag-aalis ng problema sa pabalik na ruta at sumisira sa pagkakakilanlan ng bawat kliyente.

Pumili ng isang disenyo at isulat ito, dahil kailangan ng dalawa ang magkaibang selector at magkaibang pagkakasunod-sunod ng firewall. Ang kalahating inilapat na masquerade ay napapagitna sa kanila at wala sa dalawa ang nasisiyahan. Ang nakasulat na pagpili rin ang nagpapahintulot sa susunod na inhinyero na makilala ang bug sa sadyang desisyon.

Isara ang loop sa pagpapasa at tugon

Kailangang ipasa ng gateway ang protocol at destinasyon na nilalayon mo, na nangangahulugang naka-enable ang IP forwarding at may kadena ng pagpapasa na pumapayag sa pares. Pagkatapos ay kailangang ibalik ng malayong panig ang mga tugon sa landas ng IPsec, at iyon ay desisyon sa pagruruta sa kanilang gateway at hindi sa iyo. Parehong ordinaryong configuration ang dalawang hati, at parehong madaling maiwan nang kalahati. Subukan ang mga ito nang hiwalay upang ang nawawalang patakaran sa pagpapasa ay hindi mapagkamalang sirang tunnel.

I-verify gamit ang isang tunay na kahilingan mula kliyente patungo sa aplikasyon, pinapanood itong dumaan sa interface ng OpenVPN, desisyon ng IPsec at malayong host. Suriin ang tugon bilang hiwalay na obserbasyon, dahil ang kahilingang dumarating at tugon na hindi kailanman bumabalik ay magkamukha mula sa puwesto ng kliyente. Ang isang sinusubaybayang kahilingan ay mas mahalaga kaysa sa anumang bilang ng ping mula sa gateway.

Panatilihing makitid ang awtorisasyon sa destinasyon habang nagsubok, at tiyakin na ang kliyenteng walang patakaran ay hindi maaaring maabot ang serbisyo. Ang naka-install na ruta at ang naitatag na asosasyon ay hindi katulad ng ipinagkaloob na pag-access.