Automation ng L2TP sa Android: kayang humiling ng script, hindi kayang itayo

Ang alamat ay L2TP sa Android ay isa pang bagay na kayang simulan ng shell script: magdagdag ng ruta, tawagan ang lumang serbisyo, tapos. Hindi ito maaari, dahil apat na magkaibang layer ang dapat magkasundo bago makapagdala ng pakete ang isang tunnel. Itinatag ng IPsec ang protektadong landas, dinadala ng L2TP ang session, nakikipag-usap ang PPP sa link, at dapat irehistro ng Android ang resulta bilang VPN na kayang rutahan sa paligid nito. Nakita ko itong sinubukan nang dalawang beses gamit ang kinopyang mga utos, at sa dalawang pagkakataon ay may ruta habang wala namang naka-encrypt.

Ano talaga ang nagagawa ng pagbabago ng ruta

Ang pagdagdag ng ruta ay nagpapasya kung saan pupunta ang pakete sa susunod. Hindi ito nakikipag-usap sa isang security association, hindi nagbubukas ng L2TP session, at hindi nagpapatakbo ng PPP exchange na gumagawa ng address, peer at mga setting ng DNS. Sa telepono, ang nakikitang resulta ay trapikong lumalabas sa maling ruta, o lumalabas at namamatay, na walang tunnel state kahit saan.

Ganoon din sa isang service call na kinopya mula sa lumang release. Ang panloob na VPN plumbing ng Android ay hindi isang publikadong automation API, at ang isang numeradong transaksyon mula sa ibang bersyon ay maaaring tumama sa ibang operasyon o humingi ng mga pribilehiyong wala sa script. Ang automation na nagdadala ng password ay hindi dapat kailanman umasa sa hinulaang panloob na argumento, dahil ang failure mode ay alinman sa tahimik na no-op o sa kalahating nagawang profile na walang naglilinis.

Apat na may-ari, at ang script ay wala sa kanila

Kunin sila nang sunod-sunod. Itinatag at pinapanatili ng IPsec ang protektadong ruta at pinapatunayan ang mga peer. Dinadala ng L2TP ang session sa ibabaw nito, at ang paglaganap na ito ang dahilan kung bakit itinuturing ng pamantayan ang dalawa bilang magkahiwalay na mekanismo, hindi isang protocol. Sa loob nito, nakikipag-usap ang PPP sa mga parameter ng link na gagamitin ng client. Pagkatapos, pagmamay-ari ng Android ang panig ng platform: ang nakarehistrong VPN interface, saklaw bawat app, always-on na estado at ang lifecycle na nagpapasya kung ano ang nangyayari kapag pinatay ang app.

Ang script ay makakakita lamang ng huling layer, at karaniwang hindi direkta. Maaari nitong hilingin sa client na kumonekta kung inilalantad ng client na iyon ang dokumentadong kontrol, at pagkatapos ay maaaring bantayan ang estado ng interface. Hindi nito mapapalitan ang tatlong layer sa ilalim, at hindi nito mapipilit ang platform na ituring na VPN ang isang hindi nakarehistrong interface.

Bakit hindi rin shortcut ang daemon

Ang pagsisimula ng privileged Linux daemon sa device ay mukhang nawawalang piraso, at madalas ay talagang nagpapaandar ito ng tunnel. Ang hindi nito ginagawa ay irehistro ang tunnel na iyon sa Android. Umiiral ang interface sa loob ng kernel, ngunit hindi alam ng pagpili ng VPN ng platform, routing bawat app, always-on na patakaran at lifecycle, at ang sariling mga pagbabago sa ruta at DNS ng daemon ay nakikipagkumpitensya sa network manager para sa parehong mga talahanayan.

Ang resulta ay isang koneksyon na gumagana para sa trapiko ng daemon at misteryosong hindi para sa app na mahalaga sa iyo, o isang tumatagal hanggang muling suriin ng system ang mga network nito. Wala sa mga resulta ang bug ng platform; ito ang hangganan sa pagitan ng pagmamay-ari ng socket at pagmamay-ari ng VPN facility.

Ano ang hitsura ng mga sinusuportahang ruta

Kung makakalipat ang organisasyon sa profile na ipinagkakaloob mismo ng Android, ang landas ng platform ang tapat. Mula API 30, sinusuportahan ng VpnManager ang paghahatid at pagkontrol ng mga profile ng VPN ng platform ng mga app, na may daloy ng awtorisasyon na nakakabit sa app na tumatawag. Hindi ito converter ng L2TP: ang modelong profile na ibinibigay nito para sa IKEv2 ay hindi nagsasalin ng umiiral na L2TP configuration, at ang pagpapalit ng protocol ay migrasyon, hindi pagpapalit ng pangalan. Ang mga pagkakakilanlan, ruta, pribadong DNS at mga pahintulot sa pag-access ay dapat sadyang ilipat.

Kung dapat manatiling L2TP/IPsec ang serbisyo, ang sinusuportahang kombinasyon ay isang client at release ng OS na talagang dokumentado ng operator, at ang kontrata nito sa automation kung mayroon. Kapag walang dokumentadong kontrol na walang pagmamasid, ang tamang sagot ay isang sinusuportahang manu-manong koneksyon, hindi isang marupok na privileged script na nagkataong gumagana sa isang build.

Ano ang ginagawa ng tamang automation

Kapag may dokumentadong kontrol, ang automation ay may maliit at mapagtatanggol na gawain: hilingin ang pinangalanang koneksyon, hintayin ang kahandaan, huminto sa pagkabigo ng authentication o setup, patakbuhin ang nilalayong workload, at ipaubaya ang paglilinis sa component na may-ari ng koneksyon. Nananatili ang mga kredensyal sa client na marunong mag-imbak at magpaikot ng mga ito.

Isulat kung aling component ang may-ari ng bawat layer bago isulat ang unang linya, at suriin ang resulta laban doon:

• IPsec at PPP ay pinangangasiwaan ng client, hindi ng mga ruta ng script.
• Lumalabas ang koneksyon sa VPN state ng platform, kaya ang saklaw bawat app at always-on ay nalalapat dito.
• Walang panloob na service call, numero ng transaksyon o hinulaang argumento ang nagdadala ng kredensyal.
• Ang pagkabigo sa anumang hakbang ay hindi nag-iiwan ng kalahating nakarehistrong profile.