Server VPN në Raspberry Pi: fillo nga aplikacioni i telefonit, jo nga receta

Shumica e ndërtimeve të VPN në Raspberry Pi fillojnë me recetën e serverit dhe përfundojnë me një telefon që nuk lidhet dot. Rendi është i përmbysur. Klienti në telefon zbaton një protokoll të caktuar me një shkëmbim të caktuar vërtetimi, dhe serveri duhet t'i përshtatet atij shkëmbimi, jo e kundërta. Nëse vendosni së pari aplikacionin, një pasdite e tërë korrigjimi shndërrohet në një listë të shkurtër kontrolli.

Rendi që kursen rindërtimin

Shkruaj sistemin operativ të telefonit dhe aplikacionin e saktë VPN përpara se të instalosh çdo gjë në Pi. Ky çift përcakton cili protokoll është i mundur. Një aplikacion klient nuk bëhet klient tjetër thjesht sepse profili përmban rastësisht një fushë të njohur.

Një sekret i përbashkët në profil, ose një numër porte që duket i njohur, nuk e shndërron një protokoll në tjetrin. Shkëmbimi ose përputhet me atë që zbaton aplikacioni, ose dështon në një fazë që të lë shumë pak për të lexuar. Nuk ka diagnostikim që thotë me fjalë të thjeshta "protokoll i gabuar". Merr një skadim kohe, një gabim certifikate ose një cikël të heshtur ripërpjekjesh, dhe të gjitha duken si problem i serverit.

Pasi aplikacioni është fiksuar, zgjedhja e serverit ngushtohet dhe pjesa tjetër e ndërtimit ka një objektiv.

Çfarë zbaton në të vërtetë aplikacioni i telefonit

Një listë e botuar klientësh përshkruan një aplikacion, jo një shërbim. Aplikacioni OpenVPN Connect për Android pret një server OpenVPN; ai nuk ofron anën e serverit. As nuk bëhet klient IPsec ose L2TP kur një profil duket i ngjashëm.

Ky dallim ka më shumë rëndësi kur ndjek një udhëzues më të vjetër. Recetat e shkruara për një protokoll që aplikacioni aktual e ka braktisur do të instalohen ende pastër në Pi dhe do të dështojnë ende në telefon, gjë që lexohet si gabim konfigurimi dhe jo si mospërputhje protokolli.

Kontrollo dokumentacionin aktual të aplikacionit për formatet e profilit që importon përpara se të angazhohesh për një paketë serveri. Pesë minuta lexim vlejnë më shumë se një rindërtim.

Marrëveshja katërpalëshe

Shkruaj katër gjëra dhe mbaji bashkë: sistemin operativ dhe versionin e aplikacionit të telefonit, zbatimin e serverit në Pi, politikën e vërtetimit dhe të besimit, dhe pikën e jashtme fundore. Secila nga të katërtat mund të zhvlerësojë tre të tjerat.

Një përditësim i aplikacionit, një ndryshim i paketës së serverit ose një autoritet i ri certifikatash thyejnë marrëveshjen, dhe dështimi duket identik nga telefoni çdo herë. Janë pikërisht të katërtat e shkruara që të lejojnë të identifikosh cila pjesë lëvizi.

Kredencialet kanë detyra të veçanta

Vendos nëse profili përdor certifikata klienti, emër përdoruesi dhe fjalëkalim, ose një kombinim të mbështetur, dhe bëj që të dy skajet të përputhen. Identiteti i serverit dhe materiali i CA-së së besuar gjithashtu duhet të përputhen me atë që klienti do të pranojë.

Certifikata publike e CA-së dhe çelësi privat i nënshkrimit të saj janë objekte të ndryshme. Vetëm pjesa publike i takon një profili telefoni. Vendosja e çelësit të nënshkrimit në telefon jep aftësinë për të krijuar identitete, që është e kundërta e qëllimit të një CA. Trajto atë skedar si objekti më i ndjeshëm në të gjithë ndërtimin.

Përdor rrjedhën e eksportimit dhe importimit të mbështetur nga shërbimi në vend që të montosh një profil me dorë. Profilet e montuara me dorë zakonisht mbajnë udhëzime vetëm për desktop që aplikacioni mobil i injoron ose i refuzon.

Mbi të gjitha, mos e zëvendëso vërtetimin e certifikatës me "prano çdo server" për ta bërë një shembull të vjetër të lidhet. Kjo e shndërron një problem përputhshmërie në një anashkalim vërtetimi, dhe zakonisht mbijeton deri në prodhim sepse funksionon.

Arritshmëria është një kontratë e veçantë

Telefoni duhet të arrijë pikën e jashtme fundore të serverit përmes rregullimit real në rrjedhën e sipërme. Përkthimi i ruterit të shtëpisë, filtrimi dhe NAT-i i operatorit qëndrojnë të gjitha në mes. Një emër dinamik DNS i jep pikës fundore vetëm një emër të qëndrueshëm; nuk krijon një rrugë hyrëse.

Më pas përcakto çfarë mund të arrijë klienti pas lidhjes: prefikse private ose një dalje e plotë në internet, rrugët e tyre të përcjelljes dhe përgjigjes, sjelljen e DNS-së dhe nëse IPv6 është në fushë. Një hyrje e suksesshme nuk vërteton asnjë prej tyre.

Prano telefonin dhe profilin e synuar drejtpërdrejt, duke përfshirë një kontroll që një burim i paautorizuar mbetet i paarritshëm dhe që revokimi me të vërtetë heq aksesin. Suksesi me një klient desktop vërteton atë klient desktop, jo telefonin në dorën tënde. Lista e OpenVPN Connect është një shembull konkret i një aplikacioni klient që pret një shërbim përputhës.