Kterou zdrojovou adresu zapíše NGINX pro klienta VPN?

V instalaci NGINX a OpenVPN na stejném hostiteli se objevují tři adresy klienta, jedna pro každou cestu, kterou může požadavek jít. Prohlížeč, který míří na adresu tunelu, prohlížeč, který míří na veřejnou adresu, a program, který vychází přes internetovou cestu brány, vypadají na naslouchajícím socketu různě. Než začnete řádek logu vykládat, rozhodněte, na kterou cestu se díváte. Rozhodnutí závisí na cíli, který klient použil, na výjimce, kterou má pro vnější koncový bod VPN, a na tom, zda paket po cestě něco překládá.

Rozhodujte podle cíle, ne podle toho, kdo je uživatel

Začněte adresou, na kterou byl požadavek odeslán, protože tato adresa volí cestu. Požadavek na adresu tunelu hostitele přichází na rozhraní tunelu se zdrojovou vnitřní adresou klienta. Požadavek na veřejnou adresu hostitele obvykle přichází na rozhraní obrácené do internetu s veřejnou adresou klienta, i když má stejný notebook v tu chvíli tunel navázaný. Členství v poolu VPN je proto vlastností cesty paketu, nikoli vlastností, která následuje uživatele.

Právě tento třetí řádek stojí za to zkontrolovat nejdřív, když se v logu objeví uživatel VPN s adresou, která s tunelem nemá nic společného. Vysvětluje také, proč dva uživatelé se stejným profilem mohou vytvořit různé záznamy: jejich vlastní přístupové sítě se liší a nic v tunelu to nepřepisuje.

Proč vnější koncový bod vytváří druhou veřejnou cestu

Klient se musí dostat na veřejnou adresu brány, aby tunel navázal, takže trasa k této adrese musí existovat mimo tunel. Když klient přesměruje veškerý provoz dovnitř, rozumná implementace si ponechá explicitní hostitelskou trasu k veřejné adrese serveru, aby se vyhnula tunelu, který závisí sám na sobě. Tato výjimka není vybíravá vůči službám, takže ji následuje každý požadavek na stejnou veřejnou adresu, včetně požadavku prohlížeče na web hostovaný na bráně.

To je mechanismus za většinou matoucích hlášení v této oblasti a je dán implementací klienta, nikoli serveru. Dva klienti se shodnými profily se proto mohou chovat odlišně. Odstranění výjimky, abyste log »opravili«, s sebou strhne i tunel, takže ji ponechte a navrhněte řešení kolem ní.

Čtěte socket, tabulku a formát logu společně

Tři pozorování rozhodnou, na kterou cestu se díváte: kde socket naslouchá, které rozhraní odpovídá cíli a co formát logu skutečně zaznamenává. Pokud je naslouchač vázán jen na adresu tunelu, veřejný požadavek se k němu vůbec nedostane, což hned vylučuje dva řádky. Pokud vyhledání pro klienta vrátí zařízení tunelu, požadavek dorazil s vnitřním zdrojem a log by to měl ukázat.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Pak čtěte formát, ne řádek. Pole plněné přeposlanou hlavičkou zaznamenává tvrzení, nikoli protějšek socketu, a tvrzení má význam jen tehdy, když je bezprostřední protějšek důvěryhodná proxy. Zapsání obou hodnot do logu ukončí pozdější spory, protože bezprostřední protějšek a nahrazená adresa jsou různé skutečnosti a jen jedna z nich přišla ze sítě.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Zvolte vstupní bod, který chcete, a sladěte DNS

Pokud má být web jen přes tunel, dejte mu jméno, které se klientům VPN překládá na adresu tunelu, a vynucujte politiku na naslouchajícím socketu. Odpověď split-DNS vracející 10.24.0.1 pro interní jméno je rozhodnutí o směrování v převleku za detail překladu jmen. Pokud má být web i veřejný, ponechte dvě jména nebo dva porty a nechte log říct, které z nich požadavek obsloužilo.

Pravidla allow se řídí stejnou logikou. Povolení poolu tunelu neautorizuje veřejný požadavek a nevyplní vnitřní adresu u spojení, které přišlo přes internet. Smíchání obou vstupních bodů pod jedním jménem mění zaznamenaný zdroj na vedlejší efekt směrování klienta místo návrhové volby.

Ověřte cestu, pak politiku

Potvrďte cestu zachycením na bráně a požadavkem, který ovládáte. Zachycení na zařízení tunelu a na veřejném rozhraní ukáží, které přeneslo bajty, a pořadí paketů řekne, zda mezi nimi proběhl překlad.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Potom ověřte přístup v obou směrech: zamýšlený pojmenovaný vstup funguje pro zamýšleného klienta a neschválená veřejná cesta je odmítnuta, ne jen pomalá. Obecný web s odrazem IP dokazuje něco o internetovém výstupu brány a nic o tomto webu na stejném hostiteli. Když se stránka a WebSocket rozcházejí, porovnejte jejich URL, adresní rodiny a odpovědi DNS, než se dotknete konfigurace serveru.