Proxy stále na staré adrese tunelu po opětovném připojení VPN?

Opětovné připojení může ponechat váš forwarder navázaný na adresu, kterou tunel už nevlastní. Čtyři seřazené kontroly, číslované předání a skutečný testovací požadavek.

Restart klienta VPN dokazuje jen to, že se tunel vrátil. O proxy, které mělo vycházet přes něj, to neříká nic. Squid, tinyproxy a většina dalších forwarderů drží lokální zdrojovou adresu, kterou zjistily při startu, dokud je něco nepřinutí k opětovnému načtení. Když opětovné připojení přidělí novou adresu tunelu, forwarder buď selže u každého odchozího spojení, nebo začne vycházet přes vaši běžnou trasu.

Druhá porucha je ta nebezpečná: tunel běží, stránky se načítají a špatná je jen výstupní adresa.

Začněte u posluchače, ne u tunelu

Ve hře jsou tři adresy a opětovné připojení některé z nich posune. Posluchač je místo, kam ukazuje váš prohlížeč, obvykle 127.0.0.1 nebo adresa LAN, a je mu jedno, že se tunel změnil. Odchozí lokální zdroj je to, co forwarder žádá jádro, aby použilo při vytáčení dalšího hopu, a je svázán se zařízením tunelu. Veřejný výstup je to, co zaznamená webový server, a může to být přeložená adresa několik hopů daleko.

Vyhledání veřejné IP odpovídá jen na poslední otázku. Nemůže vám říct, na kterou lokální adresu se má forwarder navázat, protože jeden veřejný výstup může skrývat několik vnitřních zdrojů. Přečtěte adresu od toho, kdo spojení vlastní: z výstupu stavu klienta, ze samotného rozhraní nebo z jmenného prostoru, kde tunel žije. Vzetí prvního rozhraní, jehož název vypadá jako tunel, dá špatnou odpověď, jakmile existuje druhý profil.

Kontejnerová a jmenná uspořádání tento předpoklad tiše boří. Forwarder v jednom síťovém jmenném prostoru se nemůže navázat na tunel, který existuje v jiném, a žádné množství úprav konfigurace to nespraví.

Čtyři kontroly, než cokoli upravíte

Projděte je v pořadí. První kontrola, která selže, je místo, kde se zastavíte, protože pozdější předpokládají, že dřívější platí.

  1. Potvrďte, že používaný tunel je profil, kolem kterého bylo proxy postaveno, ne druhý profil, který se připojil sám.
  2. Vypište adresu, která je právě na tom zařízení, a porovnejte ji s adresou v běžící konfiguraci.
  3. Zeptejte se forwarderu, jaký zdroj zjistil, ne co tvrdí soubor na disku.
  4. Potvrďte, že provoz z forwarderu skutečně podléhá směrovací a firewallové politice, kterou očekáváte.

Adresa zařízení je snadná: ip -4 addr show dev tun0 vypíše aktuální a ip -4 route get 1.1.1.1 ukáže, které rozhraní by jádro pro ten cíl zvolilo. Forwarder, který se naváže na přesnou adresu, hlasitě selže, když adresa zmizí. Forwarder, který se naváže na zařízení nebo se vrátí k výchozímu zdroji, dál funguje a uniká, a to je tichý výsledek.

Slaďte dokumentaci s vydáním, které provozujete, ne s prvním výsledkem hledání. Squidova direktiva odchozí adresy je dokumentovaná pro v7 a starší a dokumentace v8 výslovně uvádí, že tam direktiva není dostupná, takže skript postavený kolem ní tuto hranici nepřežije (viz reference Squid tcp_outgoing_address). Ověřte to vlastním parserem produktu, než se cokoli znovu načte: squid -k parse hlásí chyby a skončí, aniž by se dotkl běžícího procesu.

Číslujte každý tunel a zahoďte zastaralé výměny

Opětovné připojení je předání a předání potřebuje pořadí. Označte každé pozorované spojení čítačem nebo časovým razítkem, které roste při každém úspěšném navázání, a pak toto označení nesete uvnitř kandidátské konfigurace. Když je označení kandidáta starší než aktuální, zahoďte kandidáta místo jeho použití, protože pomalá aktualizace napsaná pro předchozí tunel by jinak přepsala nastavení pro aktuální. Slučujte nárazy událostí, aby blikající linka vytvořila jeden přechod místo patnácti.

Seřaďte práci do čtyř kroků: zneplatněte starý stav výstupu, počkejte, až vlastník spojení nahlásí dokončení, sestavte jen spravovaný fragment, poté ověřte a aktivujte přes správce služeb. Přegenerování celého souboru ze dvou hodnot adresy je způsob, jak tiše mizí omezení posluchače, autentizace a politika destinací. Respektujte i úmyslné zastavení. Pomocník, který dál vytáčí tunel, který uživatel vypnul, je chyba, ne odolnost.

Otevřené sockety novou adresu nenásledují

Rekonfigurace forwarderu neříká nic o už navázaných spojeních. Zda se vyprázdní, nebo zemřou, závisí na produktu, takže chování pozorujte, místo abyste je předpokládali.

Požadavek obsloužený přes socket otevřený před výměnou stále vychází starou cestou, i když je nová konfigurace správná. Pokud na tom záleží, rozhodněte výslovně: povolte krátké okno vyprázdnění a přestaňte přijímat novou práci, nebo ukončete staré sockety a přijměte chyby. Pak testujte novým spojením a tento výsledek držte odděleně od kontroly vyprázdnění. Navázání na zdroj také není bezpečnostní hranice. Když se provoz nikdy nesmí dotknout běžné trasy, vynuťte to značkami a pravidly firewallu včetně DNS a IPv6, aby neúspěšné načtení nechalo proxy výslovně vypnuté, ne otevřené.

Dokažte nový výstup čerstvým požadavkem

Důležitý je požadavek otevřený po aktivaci, ne ping a ne už nacacheovaná stránka. Požádejte proxy o skutečnou URL a přečtěte výstupní adresu, kterou hlásí vzdálená strana, a pak ji porovnejte s vlastním pohledem klienta na tunel, když jej poskytovatel ukazuje.

Držte parsování, opětovné načtení a požadavek jako samostatné příkazy, aby porucha ukázala na jediný krok. První dva při selhání nic nezmění, a právě proto běží před restartem.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Když opětovné načtení selže, zastavte službu a opravte fragment; proxy sloužící se zastaralým výstupem je horší než krátký výpadek. Když načtení uspěje, ale čerstvý požadavek stále vychází někam nečekaně, vraťte se ke kontrole směrování, místo abyste znovu upravovali adresy. Zapište generaci tunelu, proti které jste ověřovali, aby příští opětovné připojení mělo co konkrétně porovnávat.

Související články