Sinira ba ng upgrade ng Ubuntu ang L2TP/IPsec? Ihambing ang mga proposal ng IKEv1

Gumana ang koneksyon noong Huwebes, tumakbo ang upgrade noong Biyernes, at noong Lunes umiikot ang kliyente sa “connecting” at sumusuko. Parehong laptop, parehong server, parehong account, parehong paunang ibinahaging key. Walang na-edit sa profile, kaya ang halatang pinaghihinalaan, ang password at firewall, ay nagsasayang ng iyong oras.

Ang binago ay ang listahan ng mga transformasyong handang ialok ng iyong makina. Parehong IPsec stack na ginagamit sa Ubuntu, ang strongSwan at Libreswan, ay pumuputol ng mga algorithm na hindi na nila itinuturing na ligtas, at ang plugin ng NetworkManager sa harap nila ay may sariling listahan, na gumagalaw sa ibang iskedyul. Ang server na naka-pin sa 3DES, SHA1 at 1024-bit na Diffie-Hellman group ay maaaring mauwi sa walang marinig na tinatanggap nito.

Ano ang talagang binago ng upgrade

Dalawang layer ang nagpapakain sa proposal ng IKEv1. Nagdadala ang daemon ng naka-compile na default na set ng proposal, at ang plugin ng L2TP ay alinman sa umaasa rito o nagbibigay ng sariling listahan. Bago ang NetworkManager-l2tp 1.2.16, umaasa ang plugin rito, kaya ang iyong proposal ay ang itinuring na makatwiran ng naka-install na daemon. Mula 1.2.16, nagpapadala ang plugin ng dokumentadong listahan na hinubog sa mga kliyente ng Windows at Apple, at mas malawak ang listahang iyon kaysa sa lumang default ngunit hindi na naglalaman ng bawat lumang kumbinasyon sa unahan ng pila.

Ipinapaliwanag ng paghahating iyon ang isang paraan ng pagpalya na nakakalito para sa mga tao: maaaring magkaiba ang pag-uugali ng dalawang makina sa parehong release ng Ubuntu dahil ang isa ay may pakete ng distribusyon at ang isa ay may backport, at ang bersyon ng daemon sa pareho ay mukhang parehas sa isang ulat ng bug. Suriin ang bersyon ng plugin, hindi lang ang bersyon ng daemon, bago magpasya na walang binagong mahalaga ang upgrade.

May mas maliit na patibong sa parehong lugar. Magkaiba ang pagsulat ng dalawang daemon sa mga Diffie-Hellman group na elliptic curve, isa ang nagsusulat ng ecp384 at ang isa ay ecp_384. I-paste ang maling baybay sa dialog na Advanced at tatanggihan ng daemon ang setting bilang hindi ma-parse, na lumalabas sa log bilang problema sa negosasyon at hindi bilang typo sa configuration.

Basahin ang pagpalya bago magbago ng kahit ano

Magsimula sa kung aling backend ang pinapatakbo mo, dahil ang sagot ang tumutukoy sa syntax at lokasyon ng log.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Pagkatapos ay basahin ang palitan mismo. Sa strongSwan nagsusulat ang daemon sa journal sa kasalukuyang release at sa /var/log/syslog sa mas lumang isa, at ang kawili-wiling bahagi ay ang proposal na ipinapadala nito, hindi ang huling linya. Hinahanap mo ang pananalitang walang tugmang proposal, na problema sa algorithm; pagkabigo sa pagpapatotoo, na tumuturo sa key o account; o simpleng timeout, na tumuturo sa maaabot.

Masyadong madalas na itinuturing ang tatlong resultang ito bilang isang sintomas. Ang timeout na may walang laman na log ng daemon ay nangangahulugang hindi dumarating ang mga packet. Ang pagtanggi sa proposal ay nangangahulugang dumating ang mga ito at tinanggihan. Kung tahimik ang iyong log, taasan ang antas ng debug ng plugin para sa isang pagtatangka at ibaba ito pagkatapos, dahil mabilis napupuno ng detalyadong output ang journal.

Ang phase 1 at phase 2 ay magkahiwalay na taya

Dalawang beses nakikipagnegosasyon ang IKEv1. Binubuo ng pangunahing mode ang IKE security association mula sa isang algorithm ng encryption, isang algorithm ng integridad, isang Diffie-Hellman group at isang paraan ng pagpapatotoo. Pagkatapos ay binubuo ng mabilis na mode ang ESP association na magdadala ng L2TP. Malaya ang server na tanggapin ang una at tanggihan ang pangalawa, kaya ang kalahating tama na profile ay pumapalya nang mas huli kaysa inaasahan mo at mukhang ibang bug.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

Ang tandang padamdam ay syntax ng strongSwan para sa mahigpit na entry: ialok lamang ang isang kumbinasyong ito at wala nang iba. Kung wala ito, sumasama ang entry sa isang fallback na listahan, na mabuti kapag moderno ang kapareha at kontraproduktibo kapag ito ay appliance na may isang hard-coded na patakaran. Ituring ang pares sa itaas bilang paglalarawan ng anyo, hindi bilang rekomendasyon para sa anumang binubuo mo ngayon.

Baguhin ang isang field, pagkatapos ulitin ang pagsubok

Sa kasalukuyang plugin, ang pinakamabilis na unang pagsubok ay burahang ganap ang dalawang field ng proposal at kumonekta muli, dahil kasama na sa ibinigay na default na listahan ang mga karaniwang kumbinasyon ng Windows at Apple. Sa mas lumang plugin, ibinabalik ng pagbura sa mga ito ang kontrol sa isang daemon na maaaring itinapon na ang algorithm na pinipilit ng iyong server, at lumalala ang pagpalya.

Kung hindi tumulong ang pagbura, itakda ang mahigpit na pares na dokumentado ng iyong server, isang phase sa isang pagkakataon. Baguhin ang phase 1, kumonekta muli, at basahin ang log bago hawakan ang phase 2. Kapag gumana na sa wakas ang isang kumbinasyon, isulat ito sa tabi ng modelo ng server at bersyon ng plugin, dahil gagalaw na naman ang mga default at ang talaan na iyon ang gumagawa sa susunod na upgrade na limang minutong pagsusuri.