Tinanggihan ng iOS ang iyong strongSwan tunnel: ihambing ang mga IKE proposal

Walang anuman sa sertipiko o address ang nagpapaliwanag kung bakit ang iPhone na kumokonekta sa strongSwan noong nakaraang taon ay nabibigo ngayong taon. Walang anuman sa address, sa pre-shared key o sa pagkakakilanlan ng kliyente ang kailangang magbago. Ang gumalaw ay ang listahan ng mga transpormasyon na handang makipag-usap ng built-in na kliyente ng telepono, at kapag huminto ang listahang iyon sa pag-overlap sa listahan ng server, nagtatapos ang palitan bago pa suriin ang pagkakakilanlan ng sinuman.

Ang log line na nagpapasya

Taasan ang logging para sa koneksyong iyon at hanapin ang dalawang entry na nagpapasya sa resulta: kung ano ang inalok ng telepono at kung ano ang pinili ng server. Kung natapos ang log na walang napiling proposal at iniuulat na walang tumugma, hindi kailanman sinubukan ang authentication. Walang binabago ang bagong sertipiko at bagong password sa puntong iyon, dahil pareho silang ginagamit sa susunod na yugto. Ni isa sa kanila ay hindi makakaimpluwensya sa resultang napagpasyahan bago suriin ang pagkakakilanlan.

Paghiwalayin ang dalawang anyo ng pagkabigo bago mag-edit ng kahit ano. Walang pag-edit ng mga transpormasyon ang makakapagligtas ng tinanggihang kredensyal, at walang pagwawasto ng kredensyal ang makakapagligtas ng tinanggihang transpormasyon. Ang log entry na nagngangalan ng napiling proposal ang magsasabi kung alin sa dalawa ang kalagayan mo. Kung wala ang entry na iyon, naghuhula ka.

Ang napiling linya ay nagngangalan ng proposal sa pamamagitan ng set ng transpormasyon nito at hindi ng magiliw na label. Ihambing ang mga field ng encryption, integridad at grupo sa linyang iyon sa listahang ipinadala ng telepono, dahil sapat na ang pagkakaiba sa kahit isang field para matalo.

Ano ang nagbago sa telepono

Isang release ng iOS ang nagbawas ng mga algorithm na handang gamitin ng kliyente nito. Ang mahihinang integridad hash, maliliit na Diffie-Hellman group at mga proposal na inuuna ang lumang opsyon ay hindi na katanggap-tanggap.

Ang mas mahabang listahan ay hindi mas ligtas dito. Sinusundan ng pagpili ang tinatanggap na set ng telepono at ang sarili nitong pagkakasunod-sunod ng preperensya, kaya ang server na nag-aanunsyo ng malawak na katalogo ay maaari pa ring matalo sa negosasyon kapag ang mga modernong entry ay hindi ang napipili. Mas mainam ang maikling listahan na nauuna ang mga modernong entry. Ang mahabang listahang nagbubukas ng lumang opsyon ay tinatawag mismo ang pagkabigong sinusubukan mong iwasan. Ang tinatanggap na set ay panlabas na hadlang na gumagalaw tuwing nag-a-update ang kliyente, kaya ang config na gumana kahapon ay ebidensya tungkol kahapon.

Isang pares na nag-uusap pa rin

Para sa kasalukuyang mga telepono, sapat na ang isang modernong kombinasyon. Ganito ang hitsura ng isang pares na nag-uusap:

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

Dinadala ng ike line ang encryption, integridad at Diffie-Hellman group na ginagamit habang nagaganap ang palitan ng key. Sinasaklaw ng esp line ang data channel lamang, dahil napagpasyahan na ang grupo bago ito magkabisa. I-reload ang koneksyon o i-restart ang daemon, pagkatapos ikonekta muli ang telepono. Itago lamang ang value ng grupong iyon kung tinatanggap pa ito ng bawat kliyenteng pinaglilingkuran mo, at huwag palawakin ang proposal para sa lahat dahil lang may isang lumang peer na nangangailangan ng higit.

Tatlong lugar para ayusin, isa ay karaniwang sarado

• Isang modernong proposal para sa bawat peer. Tama kapag lahat ng kliyente ay kasalukuyang telepono at desktop. Binubura ang lumang transpormasyon sa halip na makipag-usap sa paligid ng mga ito.
• Ikalawang depinisyon ng koneksyon para sa mga kliyenteng Apple. Pinapanatiling buhay ang isang lumang peer habang binibigyan ang telepono ng proposal na tinatanggap nito. Kailangan ng isa pang bloke ng koneksyon at ginagawang nakikita ang eksepsyon.
• Ang pagpapalit ng kliyente. Bihirang bukas sa iyo: kapag isang management system o app ang naghahatid ng profile, walang proposal editor na mahahawakan, at walang ipinapakita ang built-in na kliyente.

Piliin ang ikalawang opsyon kapag ang device sa labas ng iyong kontrol ay hindi maaaring i-update. Piliin ang una kapag maaari mong iretiro ang lumang peer at mas gusto mong magdala ng isang polisiya.

Sa alinmang paraan, nakikita ang pagpili sa config, at iyon ang punto. Ang tahimik na pag-urong na nakikipag-usap pababa hanggang sa lumang transpormasyon ay mas masama kaysa sa tahasang bloke, dahil walang review na kailanman maglalabas nito.

Patunayan, pagkatapos itala

Kumonekta muli at suriin ang tatlong magkahiwalay na katotohanan sa server: may napiling proposal, lumalabas na established ang koneksyon, at nakatanggap ng address ang kliyente. Ang established na handshake na walang remote address ay tumuturo sa pool o sa mga traffic selector, at kabilang ito sa hiwalay na pagbabago. Ang pagsasama ng dalawa ay nagpapakitang hindi pa solusyunan ang isang solusyunan nang negosasyon.

Isulat ang set ng transpormasyong tinanggap, kailan mo ito binago at aling build ng kliyente ang na-verify mo. Maaaring ilipat muli ng susunod na update ang pangangailangan, at ang mga value na gumana ang unang gusto mong makita sa tabi ng mga bago.