VPN server sa Pi: simulan sa app ng telepono, hindi sa recipe

Karamihan ng pagbuo ng VPN sa Pi ay nagsisimula sa recipe ng server at nagtatapos sa teleponong hindi makakonekta. Baligtad ang pagkakasunod-sunod. Ang kliyente sa telepono ay nagpapatupad ng partikular na protocol na may partikular na palitan ng pagpapatunay, at ang server ay dapat tumugma sa palitang iyon, hindi ang kabaligtaran. Kung app muna ang pipiliin, ang buong hapon ng pag-debug ay nagiging maikling checklist.

Ang pagkakasunod-sunod na nakakatipid sa muling pagbuo

Isulat ang operating system ng telepono at ang eksaktong VPN app bago mag-install ng kahit ano sa Pi. Ang pares na ito ang nagtatakda kung aling protocol ang posible. Ang kliyenteng app ay hindi nagiging ibang kliyente dahil lang sa may pamilyar na field ang profile.

Ang shared secret sa profile, o isang port number na mukhang pamilyar, ay hindi nagpapalit ng isang protocol tungo sa iba. Ang palitan ay tumutugma sa ipinapatupad ng app, o nabigo sa yugtong kakaunti lang ang mababasa mo. Walang diagnostic na nagsasabi ng "maling protocol" sa simpleng salita. Makakakuha ka ng timeout, error sa certificate o tahimik na paulit-ulit na pagsubok, at lahat ng ito ay mukhang problema ng server.

Kapag nakapirming ang app, lumiliit ang pagpipilian ng server at may target ang natitirang pagbuo.

Ano ang aktwal na ipinapatupad ng app sa telepono

Ang nailathalang listahan ng kliyente ay naglalarawan ng aplikasyon, hindi serbisyo. Ang OpenVPN Connect app para sa Android ay umaasa sa OpenVPN server; hindi ito nagbibigay ng panig ng server. Hindi rin ito nagiging kliyente ng IPsec o L2TP kapag mukhang katulad ang profile.

Ang pagkakaibang ito ang pinakamahalaga kapag sumusunod sa lumang gabay. Ang mga recipe na isinulat para sa protocol na iniwan ng kasalukuyang app ay malinis pa ring maiinstall sa Pi at mabibigo pa rin sa telepono, na binabasa bilang error sa configuration at hindi bilang hindi pagkakatugma ng protocol.

Tingnan sa kasalukuyang dokumentasyon ng app kung aling mga format ng profile ang ini-import nito bago magpasyang gumamit ng server package. Ang limang minutong pagbabasa ay mas mabuti kaysa sa muling pagbuo.

Ang apat na bahaging kasunduan

Isulat ang apat na bagay at panatilihing magkasama: ang operating system at bersyon ng app sa telepono, ang implementasyon ng server sa Pi, ang patakaran sa pagpapatunay at pagtitiwala, at ang panlabas na endpoint. Alinman sa apat ay maaaring magpawalang-bisa sa tatlo pa.

Ang pag-upgrade ng app, pagpapalit ng server package o bagong awtoridad ng certificate ay sumisira sa kasunduan, at ang kabiguan mula sa telepono ay magkapareho tuwing may pagkakataon. Ang nakasulat na apat ang siyang nagpapahintulot na matukoy kung aling bahagi ang gumalaw.

Ang mga kredensyal ay may hiwalay na gawain

Magpasya kung gumagamit ang profile ng mga certificate ng kliyente, username at password, o suportadong kombinasyon, at pagsamahin ang dalawang dulo. Ang pagkakakilanlan ng server at ang pinagkakatiwalaang materyal ng CA ay dapat ding tumugma sa tatanggapin ng kliyente.

Ang pampublikong certificate ng CA at ang pribadong susi nito sa pagpirma ay magkaibang bagay. Tanging ang pampublikong bahagi ang nabibilang sa profile ng telepono. Ang paglalagay ng susi sa pagpirma sa telepono ay nagbibigay ng kakayahang lumikha ng mga pagkakakilanlan, na kabaligtaran ng layunin ng CA. Ituring ang file na iyon na pinakasensitibong bagay sa buong pagbuo.

Gamitin ang suportadong daloy ng pag-export at pag-import ng serbisyo sa halip na buuin ang profile gamit ang kamay. Ang mga profile na ginawa sa kamay ay kadalasang may mga direktiba para sa desktop lamang na binabalewala o tinatanggihan ng mobile app.

Higit sa lahat, huwag palitan ang pagpapatunay ng certificate ng "tumanggap ng anumang server" para makakonekta ang lumang halimbawa. Ginagawa nitong pag-iwas sa pagpapatunay ang problema sa pagiging tugma, at kadalasan ito ay nananatili hanggang produksyon dahil gumagana ito.

Ang maabot ay hiwalay na kontrata

Kailangang maabot ng telepono ang panlabas na endpoint ng server sa pamamagitan ng tunay na kaayusan sa upstream. Ang pagsasalin ng home router, pag-filter at NAT ng operator ay nasa pagitan ng dalawa. Ang dynamic na DNS name ay nagbibigay lamang ng matatag na pangalan sa endpoint; hindi ito lumilikha ng papasok na landas.

Pagkatapos, tukuyin kung ano ang maaabot ng kliyente kapag nakakonekta: mga pribadong prefix o buong labasan sa internet, ang kanilang mga landas ng pagpapasa at pagtugon, pag-uugali ng DNS, at kung saklaw ang IPv6. Walang pinatutunayan ang matagumpay na pag-login sa mga iyon.

Tanggapin nang direkta ang inilaan na telepono at profile, kasama ang pagsusuring nananatiling hindi maabot ang isang hindi awtorisadong mapagkukunan at talagang inaalis ng pagbawi ang access. Ang tagumpay sa kliyente ng desktop ay nagpapatunay sa kliyenteng iyon, hindi ang teleponong nasa kamay mo. Ang listahan ng OpenVPN Connect ay isang konkretong halimbawa ng kliyenteng aplikasyon na umaasa sa katugmang serbisyo.