VPN server na Raspberry Pi: začnite aplikáciou v telefóne, nie receptom

Väčšina stavieb VPN na Raspberry Pi sa začína receptom na server a končí telefónom, ktorý sa nepripojí. Poradie je opačné. Klient v telefóne implementuje konkrétny protokol s konkrétnou autentifikačnou výmenou a server sa musí prispôsobiť tejto výmene, nie naopak. Ak najprv zvolíte aplikáciu, celé popoludnie ladenia sa zmení na krátky kontrolný zoznam.

Poradie, ktoré ušetrí prestavbu

Predtým, ako na Pi čokoľvek nainštalujete, zapíšte operačný systém telefónu a presnú VPN aplikáciu. Táto dvojica určuje, ktorý protokol je vôbec možný. Klientska aplikácia sa nestane iným klientom len preto, že profil náhodou obsahuje známe pole.

Zdieľané tajomstvo v profile alebo známe vyzerajúce číslo portu nepremení jeden protokol na iný. Výmena buď zodpovedá tomu, čo aplikácia implementuje, alebo zlyhá vo fáze, ktorá vám dá veľmi málo na čítanie. Neexistuje diagnostika, ktorá by jednoduchými slovami povedala "nesprávny protokol". Dostanete vypršanie časového limitu, chybu certifikátu alebo tichú slučku opakovania a všetko to vyzerá ako problém servera.

Keď je aplikácia pevná, výber servera sa zúži a zvyšok stavby má cieľ.

Čo aplikácia v telefóne skutočne implementuje

Zverejnený zoznam klientov opisuje aplikáciu, nie službu. Aplikácia OpenVPN Connect pre Android očakáva server OpenVPN; serverovú stranu neposkytuje. Nestane sa ani klientom IPsec alebo L2TP, keď profil vyzerá podobne.

Tento rozdiel je najdôležitejší pri staršom návode. Recepty napísané pre protokol, ktorý súčasná aplikácia opustila, sa na Pi stále čisto nainštalujú a v telefóne stále zlyhajú, čo vyzerá ako chyba konfigurácie, a nie ako nezhoda protokolu.

Predtým, ako sa zaväžete k balíku servera, pozrite sa do aktuálnej dokumentácie aplikácie, aké formáty profilov importuje. Päť minút čítania je lepších ako prestavba.

Štvorstranná dohoda

Zapíšte štyri veci a držte ich spolu: operačný systém a verziu aplikácie v telefóne, implementáciu servera na Pi, politiku autentifikácie a dôvery a vonkajší koncový bod. Ktorákoľvek zo štyroch môže zneplatniť ostatné tri.

Aktualizácia aplikácie, zmena balíka servera alebo nová certifikačná autorita dohodu rozbijú a zlyhanie z telefónu vždy vyzerá rovnako. Práve zapísané štyri umožňujú určiť, ktorá časť sa posunula.

Prihlasovacie údaje majú oddelené úlohy

Rozhodnite, či profil používa klientske certifikáty, používateľské meno a heslo alebo podporovanú kombináciu, a zlaďte oba konce. Identita servera a materiál dôveryhodnej CA tiež musia zodpovedať tomu, čo klient prijme.

Verejný certifikát CA a jej podpisový súkromný kľúč sú rôzne objekty. Do profilu telefónu patrí len verejná časť. Umiestnenie podpisového kľúča do telefónu odovzdáva schopnosť vytvárať identity, čo je opak účelu CA. Zaobchádzajte s tým súborom ako s najcitlivejším objektom celej stavby.

Použite podporovaný exportný a importný postup služby namiesto ručného skladania profilu. Ručne zostavené profily zvyčajne nesú direktívy len pre počítače, ktoré mobilná aplikácia ignoruje alebo odmieta.

Predovšetkým nenahrádzajte overenie certifikátu voľbou "prijmi akýkoľvek server", aby sa starý príklad pripojil. To mení problém kompatibility na obchádzanie autentifikácie a zvyčajne prežije až do produkcie, pretože funguje.

Dostupnosť je samostatná zmluva

Telefón sa musí dostať na vonkajší koncový bod servera skutočným usporiadaním proti prúdu. Preklad domáceho routera, filtrovanie aj NAT operátora stoja medzi nimi. Dynamické meno DNS dáva koncovému bodu len stabilné meno; nevytvára vstupnú cestu.

Potom určite, čo klient po pripojení smie dosiahnuť: súkromné prefixy alebo plný výstup do internetu, ich cesty preposielania a odpovedí, správanie DNS a či je IPv6 v rozsahu. Úspešné prihlásenie nič z toho nedokazuje.

Prijmite zamýšľaný telefón a profil priamo, vrátane kontroly, že neoprávnený zdroj zostáva nedostupný a že odvolanie skutočne odoberie prístup. Úspech s počítačovým klientom potvrdzuje tento počítačový klient, nie telefón vo vašej ruke. Zoznam OpenVPN Connect je konkrétnym príkladom klientskej aplikácie, ktorá očakáva zodpovedajúcu službu.