Bakit kumokonekta ang Android sa home IPsec VPN samantalang ang Windows ay hindi

Sumasali ang telepono sa VPN ng router nang walang reklamo habang ang laptop sa parehong Wi-Fi ay hindi makakaya. Pareho ang kredensyal, pareho ang server, pareho ang minuto. Ang pagkakaiba ay suporta sa protocol at hindi ang password: naglalabas ang router ng profile na ipinapatupad ng isang operating system at hindi kailanman ginawa ng isa.

Tukuyin muna ang profile, pagkatapos ihambing ito sa aktwal na sinasalita ng bawat kliyente.

Isang menu, tatlong protocol

Sa ilalim ng isang heading ng IPsec, maaaring magtago ang firmware ng consumer ng tatlong lubos na magkakaibang tunnel. Ang una ay IKEv1 na may XAUTH: isang pinagsasaluhang group secret, pagkatapos ay username at password sa ibabaw. Ang pangalawa ay L2TP/IPsec, kung saan tumatakbo ang PPP sa loob ng IPsec transport na pinoprotektahan ng pinagsasaluhang key. Ang pangatlo ay IKEv2, na ina-authenticate gamit ang mga certificate o EAP.

Basahin ang mga field, hindi ang label. Ang group secret at listahan ng user ay nangangahulugang IKEv1 XAUTH. Ang pinagsasaluhang key at PPP account ay nangangahulugang L2TP/IPsec. Ang server certificate na walang group secret ay nangangahulugang IKEv2.

Ang agwat ng suporta sa pagitan ng telepono at laptop

May bitbit na IKEv1 XAUTH PSK client ang Android, at iyon mismo ang dahilan kung bakit nagtatagumpay ang telepono sa router na walang ibang inaalok. Walang ganoon ang Windows: ang native na client nito ay humahawak ng L2TP/IPsec at IKEv2, at walang opsyon na IKEv1 XAUTH na maaaring i-enable. Walang maitutulong ang muling paglalagay ng secret, dahil ang kulang na piraso ay ang protocol at hindi ang kredensyal.

Ang panig ng Apple ay gumagalaw na target. Ang mas bagong macOS at iOS release ay patungo sa IKEv2, ang mga lumang Cisco-style profile ay nananatili sa ilang build, at ang isang upgrade ay maaaring magtanggal o maghigpit ng gumana noong nakaraang buwan. Ang Mac na kumonekta kahapon at hindi ngayon, na walang pagbabago sa router, ay karaniwang ito.

Dalawang setting na sumisira sa ibang tama na profile

Ang pahina ng Synology para sa L2TP/IPsec ay nag-aalok ng checkbox na may label na Enable SHA2-256 compatible mode (96 bit). Tinatanggihan ng mga Apple client mula iOS 14 at macOS Big Sur pataas ang pinutol na mode na iyon, kaya kailangang alisin ang tsek para sa kanila. Kapag naiwang naka-on, nag-a-authenticate ang tunnel at pagkatapos ay bumabagsak, na mukhang masamang kredensyal at hindi naman. Dinodokumento ng vendor ang toggle, at ang karaniwang sandali na nagsisimula itong maging mahalaga ay isang upgrade ng operating system.

Inihahawak ng Windows ang mga certificate sa dalawang hiwalay na tindahan, at binabasa lamang ng IKEv2 ang sa makina. I-import ang client certificate kasama ang private key nito sa computer account; ang certificate na nakalagay sa ilalim ng iyong user account ay lumilitaw sa management console at hindi kailanman nakakarating sa IKEv2 service. Ang EAP-TLS ang tanging kaso kung saan magagamit ang user certificate, at kailangan pa ring pagkatiwalaan ng makina ang signing CA. Ang pagkakamali dito ay lumalabas bilang authentication failure, hindi bilang hiling ng nawawalang certificate.

Kapag nananatili ang router kung ano ito

Ang router na XAUTH PSK lamang ang sinasalita ay nag-iiwan ng tatlong paraan pasulong: ang client ng vendor, isang third-party client na nagpapatupad pa rin ng profile, o ilipat ang dulo ng tunnel sa isang bagay na nagsasalita ng IKEv2. Ang AVM, halimbawa, ay naglalathala ng Windows client software at isang na-export na configuration file para sa mga router nito. Sinusuportahan ang rutang iyon, at nangangahulugan ito ng pag-install ng tool ng vendor sa bawat laptop.

Mas mahalaga ang suporta kaysa sa kagandahan kapag ang mga laptop ay hindi sa iyo para itayo muli.

Timbangin din ang halaga sa seguridad. Sinasaklaw ng isang group secret ang bawat user, kaya sinumang may hawak nito ay maaaring pumalit sa server at mahuli ang username at password na inaalok ng client. Kung saan magagamit ang IKEv2 na may mga certificate, mas mahalaga ang paglilipat na iyon kaysa sa anumang client workaround.

Suriin mula sa labas papasok

Kumuha muna ng isang gumaganang session mula sa telepono, upang mapatunayan ang panig ng server bago pumasok ang laptop sa larawan. Pagkatapos ay i-import ang na-export na profile ng router nang walang pagbabago at basahin ang client log sa halip na ang status page ng router. Kung walang proposal na lumalabas sa log, hindi kailanman naabot ng laptop ang responder. Kung may mga proposal na nagpapalitan at pagkatapos ay nabigo, ang hindi pagkakasundo ay tungkol sa algorithm, pagkakakilanlan o kredensyal.

Panatilihin ang gumaganang profile ng telepono bilang kontrol. Kapag ang laptop lamang ang nasira pagkatapos ng firmware update, kumikilos ang panig ng server na gaya ng dati. Kapag pareho silang nasira, tingnan ang certificate o ang listener bago hawakan ang alinman sa mga client.