VPN server na Raspberry Pi: začněte aplikací v telefonu, ne receptem

Většina staveb VPN na Raspberry Pi začíná receptem na server a končí telefonem, který se nepřipojí. Pořadí je obrácené. Klient v telefonu implementuje konkrétní protokol s konkrétní autentizační výměnou a server se musí přizpůsobit této výměně, ne naopak. Když nejdřív zvolíte aplikaci, celé odpoledne ladění se změní v krátký kontrolní seznam.

Pořadí, které ušetří přestavbu

Než na Pi cokoli nainstalujete, zapište operační systém telefonu a přesnou VPN aplikaci. Tato dvojice určuje, který protokol je vůbec možný. Klientská aplikace se nestane jiným klientem jen proto, že profil náhodou obsahuje známé pole.

Sdílené tajemství v profilu nebo známě vypadající číslo portu nepřemění jeden protokol v jiný. Výměna buď odpovídá tomu, co aplikace implementuje, nebo selže ve fázi, která vám dá velmi málo ke čtení. Neexistuje diagnostika, která by prostými slovy řekla "špatný protokol". Dostanete vypršení časového limitu, chybu certifikátu nebo tichou smyčku opakování a všechno to vypadá jako problém serveru.

Jakmile je aplikace pevná, volba serveru se zúží a zbytek stavby má cíl.

Co aplikace v telefonu skutečně implementuje

Zveřejněný seznam klientů popisuje aplikaci, ne službu. Aplikace OpenVPN Connect pro Android očekává server OpenVPN; serverovou stranu neposkytuje. Nestane se ani klientem IPsec nebo L2TP, když profil vypadá podobně.

Tento rozdíl je nejdůležitější, když se držíte staršího návodu. Recepty napsané pro protokol, který současná aplikace opustila, se na Pi stále čistě nainstalují a v telefonu stále selžou, což vypadá jako chyba konfigurace, a ne jako neshoda protokolu.

Než se zavážete k balíčku serveru, podívejte se do aktuální dokumentace aplikace na formáty profilů, které importuje. Pět minut čtení je lepších než přestavba.

Čtyřdílná dohoda

Zapište čtyři věci a držte je pohromadě: operační systém telefonu a verzi aplikace, implementaci serveru na Pi, politiku autentizace a důvěry a vnější koncový bod. Každá ze čtyř může zneplatnit zbývající tři.

Aktualizace aplikace, změna balíčku serveru nebo nová certifikační autorita dohodu rozbijí a selhání z telefonu pokaždé vypadá stejně. Právě zapsané čtyři položky vám umožní určit, která část se posunula.

Přihlašovací údaje mají oddělené úkoly

Rozhodněte, zda profil používá klientské certifikáty, uživatelské jméno a heslo, nebo podporovanou kombinaci, a slaďte oba konce. Identita serveru a materiál důvěryhodné CA také musí odpovídat tomu, co klient přijme.

Veřejný certifikát CA a její podepisovací soukromý klíč jsou různé objekty. Do profilu telefonu patří jen veřejná část. Když podepisovací klíč vložíte do telefonu, rozdáte schopnost vyrábět identity, což je opak toho, k čemu CA slouží. Zacházejte s tím souborem jako s nejcitlivějším objektem celé stavby.

Použijte podporovaný exportní a importní postup služby, místo abyste profil skládali ručně. Ručně sestavené profily obvykle nesou direktivy jen pro počítače, které mobilní aplikace ignoruje nebo odmítá.

Především nenahrazujte ověření certifikátu volbou "přijmi jakýkoli server", abyste starý příklad přinutili se připojit. To mění problém kompatibility v obcházení autentizace a obvykle přežije až do produkce, protože funguje.

Dostupnost je samostatná smlouva

Telefon se musí dostat na vnější koncový bod serveru skutečným uspořádáním proti proudu. Překlad domácího routeru, filtrování i NAT operátora stojí mezi nimi. Dynamické jméno DNS dává koncovému bodu jen stabilní jméno; nevytváří vstupní cestu.

Pak určete, co klient po připojení smí dosáhnout: soukromé prefixy nebo plný výstup do internetu, jejich cesty předávání a odpovědí, chování DNS a zda je IPv6 v rozsahu. Úspěšné přihlášení nic z toho nedokazuje.

Přijměte zamýšlený telefon a profil přímo, včetně kontroly, že neoprávněný zdroj zůstává nedostupný a že odvolání skutečně odebere přístup. Úspěch s počítačovým klientem potvrzuje tento počítačový klient, ne telefon ve vaší ruce. Seznam OpenVPN Connect je konkrétním příkladem klientské aplikace, která očekává odpovídající službu.