OpenVPN PHP-krok: trusted_ip mot ifconfig_pool_remote_ip

En tom $_ENV-matrise i et krokskript føles som bevis på at OpenVPN ikke sendte noe. Vanligvis er det bevis på noe helt annet: PHP var konfigurert til ikke å fylle den superglobale variabelen, og verdiene lå i prosessmiljøet hele tiden. Den andre feilaktige slutningen er mer subtil, fordi de to adressevariablene i en tilkoblingskrok betyr forskjellige ting og brukes om hverandre. Begge feilene koster en ettermiddag hvis du starter med den gale.

To adresser, to forskjellige påstander

Det ytre endepunktet er det serveren observerte da klienten koblet til, tilgjengelig som trusted_ip for IPv4 og trusted_ip6 for IPv6. Den virtuelle adressen er det utvalget tildelte for denne økten, tilgjengelig som ifconfig_pool_remote_ip.

De svarer på forskjellige spørsmål, og en post trenger vanligvis én av dem, ikke begge. Den første er hvor tilkoblingen kom fra, som kan være en delt NAT-adresse brukt av hundrevis av mennesker. Den andre er hvor denne økten bor inne i tunnelen, og den kan tildeles en annen økt senere. Å blande de to gir poster som ser rimelige ut og er gale.

En minimal lesing ser slik ut.

$outer4 = getenv('trusted_ip');
$outer6 = getenv('trusted_ip6');
$inner  = getenv('ifconfig_pool_remote_ip');
$outer  = $outer4 !== false ? $outer4 : $outer6;

Ingen av verdiene identifiserer en person. Den ene er en nettverksobservasjon, den andre en leie, og en post som behandler noen av dem som en stabil enhetsidentifikator vil være gal første gang en klient kobler til på nytt fra et annet nettverk eller får en annen utvalgsadresse. Velg feltet etter spørsmålet posten må svare på, og skriv det spørsmålet ved siden av kolonnen.

Sjekk hvordan PHP ble startet, ikke skallet ditt

Kroken kjører som et barn av VPN-demonen med et miljø demonen bygger. Det interaktive skallet ditt har et annet, og å kjøre skriptet for hånd tester skallets miljø, ikke krokens.

Begynn med å bekrefte at kroken faktisk utløste på stadiet du forventet. Et skript festet til feil stadium, eller et som aldri kjørte fordi direktivet peker på en annen sti, gir nøyaktig samme symptom som en manglende variabel. Legg inn en bevisst markørlinje øverst i skriptet og bekreft at den vises før du undersøker noe annet. Én tidsstemplet linje i loggen skiller «kjørte aldri» fra «kjørte uten verdien».

Bekreft deretter hvilken tolk og hvilken konfigurasjonsfil den kjøringen bruker. Å endre PHP-konfigurasjonen for en webserver endrer ingenting for en CLI-prosess startet av OpenVPN, og de to kan laste helt forskjellige php.ini-filer.

Hvorfor et tomt $_ENV ikke beviser noe

PHPs getenv-referanse dokumenterer en direkte lesing av prosessmiljøet, som returnerer false når navnet mangler. Superglobalen $_ENV fylles separat, og direktivet variables_order avgjør hvilke superglobaler som fylles.

Hvis det direktivet utelater E, forblir $_ENV tom uansett hva miljøet inneholder. Kode som indekserer den rapporterer da en manglende variabel som faktisk finnes, og undersøkelsen går mot OpenVPN mens svaret ligger i php.ini. Sjekk direktivet spesielt for CLI-konfigurasjonen, ikke for webserveren.

Lesing med getenv unngår hele denne forvirringen, og et innpakningsskript som tømmer miljøet før det kaller tolken, gjeninnfører den i en annen form.

Lagre en tilknytning, ikke en radoppdatering

Bestem hvilken verdi posten trenger før du skriver den. Hvis målet er å notere hvor en økt kom fra, lagre det ytre endepunktet og merk det som en observasjon. Hvis målet er å knytte en økt til en tunneladresse for varigheten av en tilkobling, lagre utvalgsadressen og nøkle den til økten.

Oppdater etter den autentiserte identiteten og den gjeldende økten, ikke etter hver rad som deler en tunneladresse, fordi utvalgsadresser gjenbrukes og en sen frakoblingshendelse ellers kan overskrive dataene til en nyere tilkobling. Håndter IPv6 eksplisitt i stedet for å skrive bare IPv4-verdien i stillhet. En rad med NULL ytre adresse er bedre enn en rad med feil, fordi den første er synlig ufullstendig.

Nøkle skrivingen til øktidentifikatoren OpenVPN gir, slik at en ny tilkobling lager en ny post i stedet for å redigere den gamle. Bruk parameteriserte utsagn og en konto med bare tillatelsene operasjonen trenger. En krok kjører med demonens myndighet, så en uforsiktig spørring er et større problem enn en feil logglinje.

Diagnostiser uten å dumpe miljøet

Logg hvilke navn som var til stede, hvilket stadium som kjørte og hvilken tolk som ble brukt. Ikke skriv ut hele miljøet, fordi en krokprosess kan arve urelaterte verdier som ikke bør havne i en loggfil.

Verifiser én tilkobling fra ende til annen: les det ytre endepunktet, les den tildelte adressen, og bekreft begge mot serverens eget syn på den økten. Når paret er bekreftet for én klient, kan tilknytningen stole på andre steder.