vpnc laban sa Check Point o Nortel: bakit ito nag-hang

Madaling mabasa nang mali ang sintomas: nagsisimula ang vpnc, nagtatanong ng group password, pagkatapos ay tumatayo sa isang hakbang ng negosasyon hanggang mag-ulat ito na walang sagot mula sa target. Wala sa output ang nagbabanggit ng produkto ng gateway, at gumagana ang account mula sa browser, kaya ang halatang konklusyon ay maling password o naka-block na port. Sa karamihan ng mga kasong ito ang gateway ay hindi talaga IPsec peer, kaya hindi kailanman umaabot ang palitan hanggang sa pagsubok ng kredensyal. Sulit subukan ang pattern na ito bago baguhin ang anupaman sa profile.

Kilalanin ang produkto bago i-edit ang ibang field ng profile.

Ang kabiguan ay mukhang maling kredensyal

Nagsisimula ang vpnc sa pagpapadala ng IKE sa UDP 500 at, kung inaalok ang NAT traversal, sa UDP 4500. Ang gateway na nagtatapos ng SSL sa halip na IPsec ay hindi sumasagot sa alinman, kaya nag-uumulit ang kliyente at sa huli ay sumusuko nang may pangkalahatang error. Kung gumagana ang parehong account sa pamamagitan ng portal sa browser na naglo-load ng maliit na helper application, malakas na senyales ito na naka-base sa SSL ang tunnel at mali ang itinatanong ng kliyente.

Ang bigong pagtatangka dito ay walang sinasabi tungkol sa account ng gumagamit, dahil kailanman walang kredensyal na iniharap sa gateway.

Tingnan kung aling protocol ang inaalok ng gateway

Dalawang minuto ng pagsisiyasat ang naghihiwalay sa IPsec peer at sa SSL portal. Patakbuhin ang mga ito mula sa parehong network na gagamitin ng kliyente, at basahin kung aling mga port ang sumasagot, hindi kung alin ang nakasulat sa isang dokumento. Itago ang resulta, dahil ang mismong mga port na iyon ang nagtatakda kung aling kliyente ang dapat suportahan ng may-ari ng gateway. Magsiyasat mula sa network ng kliyente at hindi mula sa host sa tabi ng gateway.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

Isang bukas na 443 na may redirect sa login page at katahimikan sa 500 at 4500 ay tumutukoy sa SSL VPN. Bukas na 500 at 4500 na may sertipikong inihahain sa 443 ay nagmumungkahi ng IPsec gateway na nagpapatakbo rin ng web frontend, at iyon ang kasong ginawa ng vpnc.

Ang SSL Network Extender ng Check Point at ang Aventail client ng Nortel ay parehong nasa ikalawang kategorya, at wala sa kanila ang tumatanggap ng IKEv1 group secret.

Ano ang maipapahayag ng vpnc profile at ano ang hindi

Sa ilalim ng hood, pinapatakbo ng vpnc ang IKEv1 laban sa group na paunang ibinahaging key, pagkatapos ay ipinapadala ang kredensyal ng indibidwal na gumagamit sa pamamagitan ng XAuth. Ang lahat sa configuration file nito ay kabilang sa palitang iyon: gateway, pangalan ng grupo, group secret, username at password ng gumagamit. Inilalarawan ng mga field na ito ang isang protocol, at walang kumbinasyon nila ang makapagpapasalita sa kliyente ng iba.

Kaya't ang pagpapalawak ng cipher list o pag-off ng mga pagsusuri ng sertipiko ay hindi kailanman nag-aayos ng ganitong uri ng kabiguan. Pinapahina ng mga pagbabagong iyon ang negosasyong hindi pinakikinggan ng gateway.

Pagpili ng kliyenteng tugma sa gateway

Para sa Check Point gateway, gamitin ang SNX package na binuo para sa release ng gateway na iyon, na inilalathala ng vendor kasama ng dokumentasyon nito sa remote access. Madalas mabigo ang mas lumang SNX builds sa kasalukuyang distribusyon dahil inaasahan nila ang 32-bit libraries na hindi na naka-install, at ang pag-patch ng inabandonang package ay karaniwang mas masama kaysa sa pagpapatakbo ng sinusuportahang kliyente sa sinusuportahang platform.

Nawala ang suporta ng mga Aventail client matagal na. Kung saan gumagana pa ang gayong gateway, ang makatotohanang pagpipilian ay ang portal sa browser kung papaganahin ito ng organisasyon, o ang sinusuportahang kliyente ng vendor sa sinusuportahang operating system.

Tanungin ang may-ari ng gateway tungkol sa produkto at bersyon, sa kliyenteng sinusuportahan nila sa Linux, at kung may profile na IPsec man. Kung mayroon, hilingin ang group identifier at group secret bilang magkahiwalay na aytem, dahil hindi iyon ang password ng gumagamit at ang pinagpalit na pares ang isa pang karaniwang dahilan ng bigong tunnel. Kapag nagtagumpay sa wakas ang koneksyon, itala kung aling protocol ang napagkasunduan upang ang susunod na tao ay magsimula sa katotohanan sa halip na ulitin ang parehong haka-haka.