Android OpenVPN: tilføj en privat rute uden at roote telefonen

Du mangler et ekstra privat subnet — sig 10.60.0.0/24 — som profilen ikke indeholder i øjeblikket. På en bærbar computer ville du tilføje en rute og komme videre. På Android er VPN'en en app, tun-enheden tilhører den app, og der er ingen routingtabel, du kan redigere uden root. Ruten skal stadig findes, men den skal ind i den profil, klienten indlæser, og den virker kun, hvis den anden side er enig. Her er redigeringen, genopkoblingen, serversiden og tilbagerulningen.

Før redigeringen: hvad en rute kan og ikke kan

En rute besvarer ét spørgsmål: hvilken grænseflade der skal bære trafikken til denne destination. Den godkender ikke noget. Hvis netværkets ejer ikke har accepteret, at denne telefon må nå det subnet, giver en korrekt rute en konfiguration, der ser korrekt ud, og et stille drop i gatewayen, og du bruger den næste time på at redigere den forkerte fil.

Skaf den aftale først, skriftligt hvis netværket har en ejer. Noter derefter, hvad du ikke gør: du tildeler ikke telefonen en adresse inde i det LAN, du ændrer ikke serverens listener, og du vælger ikke et site efter værtsnavn. Det er fire forskellige ændringer, og kun den første er din.

Redigér den profil, klienten faktisk indlæser

For en kompatibel klient, der importerer almindelig OpenVPN-optionstekst, er tilføjelsen én linje:

route 10.60.0.0 255.255.255.0

Føj den til profilens krop, nær de andre routingdirektiver, og hold operatørens endpoint, certifikater, nøglehåndtering og verifikationslinjer præcis som de var. Indsæt ikke et helt gammelt eksempel for at låne én linje: komprimering, absolutte filstier og forældede cipher-indstillinger følger med og koster dig en separat fejlfindingssession.

Det trin, folk overser, er ejerskabet til filen. Hvis appen importerede en profil, er den kopi, den bruger, appens, og redigering af den downloadede original ændrer intet. Brug klientens understøttede editor, eller genimporter den redigerede fil via opdateringsvejen, og bekræft den aktive profils navn, når flere lignende navne findes. Noter, hvilken du ændrede.

Hvis profilen allerede indeholder route-nopull, installeres ingen rute fra serveren, og hvert præfiks, telefonen har brug for, skal angives eksplicit. Det er et legitimt design, men det betyder, at en udeladt linje ser præcis ud som en afvisning fra serveren.

Genopkobl og verificér på enheden

Afbryd først, og genopkobl derefter den specifikke profil, du redigerede, i stedet for at lade appen gendanne den sidste session. Åbn forbindelsesloggen, og bekræft, at klienten har parset den nye linje; et routedirektiv, som frontenden ignorerer, er et almindeligt resultat af at redigere den forkerte kopi.

Test destinationen efter adresse, ikke efter navn. Et TCP-tjek til én kendt serviceport er mere informativt end en ping, fordi mange værter svarer på ICMP, mens serviceporten er filtreret. Hvis adressen svarer, og et navn ikke gør, har du et resolver-spørgsmål snarere end et routing-spørgsmål, og næste afsnit er ikke til dig.

To scope-tjek hører også her. Per-app VPN betyder, at en adresserute kan være til stede, mens den app, du tester med, er uden for det inkluderede sæt, så test med en app, der faktisk er indenfor. Og et IPv4-præfiks siger intet om IPv6-stien; hvis tjenesten er dual-stack, skal du tilføje den tilsvarende IPv6-rute eller forvente, at klienten foretrækker en sti, du ikke havde til hensigt.

Et negativt resultat er værd at genkende tidligt: hvis en full-tunnel-rute allerede dækker 0.0.0.0/0, mangler præfikset ikke, og at tilføje det igen ændrer intet. Dobbelt dækning reparerer ikke en afvisning på serversiden eller et manglende svar.

Færdiggør stien på serveren

Tre ting skal være sande ud over telefonen. Gatewayen har brug for en rute til destinationen og tilladelse til at videresende telefonens kilde mod den. Målet skal acceptere den kilde og returnere svar gennem gatewayen, eller designet har brug for bevidst oversættelse på egress. OpenVPN-manualens route-indstilling dækker klientdirektivet; videresendelse og returrouting er separate indstillinger på separate maskiner.

Hvis destinationen ligger bag en anden VPN-klient i stedet for direkte bag gatewayen, har serveren brug for en iroute til den peers subnet. Det direktiv ejes af serveren og beskriver, hvilken klient der ejer et præfiks; en telefon kan ikke levere det fra sin egen profil, og ingen mængde klientredigering erstatter det.

Kontrollér returvejen eksplicit. Et svar, der forlader via standardruten i stedet for tunnelen, giver det klassiske halvåbne symptom: forbindelsen er etableret i én retning, og intet kommer tilbage. Kildetranslation på gatewayen er en legitim løsning, når målet ikke kan route tilbage, men det er en politikbeslutning med egne konsekvenser.

Tilbagerulning og accept

Gem den forrige profil, før du redigerer den. Hvis ændringen gør tingene værre, gendan den kopi via samme genimporteringsvej, genopkobl, og bekræft, at den gamle adfærd vender tilbage — det bekræfter, at du ændrede det, du troede, du ændrede. En tilbagerulning, der ikke gendanner den gamle tilstand, betyder, at appen holder en tredje kopi, du ikke har fundet.

Acceptér ændringen, når fire ting holder, testet i denne rækkefølge efter en frisk genopkobling: destinationen svarer på sin serviceport, det private navn slår op, hvis det forventes, HTTPS validerer stadig det tilsigtede værtsnavn, og det hele virker stadig efter en genstart eller et skift fra Wi-Fi til mobilnet. Det sidste tjek er det, der fanger en rute, der kun findes, indtil Android genetablerer tunnelen.

• Bekræft, at netværkets ejer tillader destinationen, før du redigerer noget.
• Sæt ruten i den profil, klienten indlæser, og genimporter og genopkobl derefter.
• Verificér via serviceport, inden for per-app-scope, for den rigtige adressefamilie.
• Ret videresendelse, returrouting og iroute på serveren, ikke på telefonen.
• Gem en tilbagerulningskopi, og test igen efter en genstart.