Zostal proxy na starej adrese tunela po opätovnom pripojení VPN?

Reštart klienta VPN dokazuje len to, že tunel sa vrátil. O proxy, ktorému bolo povedané, aby vychádzal cezeň, nehovorí nič. Squid, tinyproxy a väčšina ostatných preposielačov drží lokálnu zdrojovú adresu zistenú pri štarte, kým ich niečo neprinúti znova načítať. Keď opätovné pripojenie pridelí novú adresu tunela, preposielač buď zlyhá pri každom odchádzajúcom spojení, alebo začne vychádzať vašou obvyklou trasou.

Druhá porucha je tá nebezpečná: tunel beží, stránky sa načítavajú a nesprávna je len výstupná adresa.

Začnite pri poslucháčovi, nie pri tuneli

V hre sú tri adresy a opätovné pripojenie posúva len niektoré. Poslucháč je miesto, kam ukazuje váš prehliadač, zvyčajne 127.0.0.1 alebo adresa LAN, a nezaujíma ho, že sa tunel zmenil. Odchádzajúci lokálny zdroj je to, čo preposielač žiada jadro použiť pri vytáčaní ďalšieho skoku, a je viazaný na zariadenie tunela. Verejný výstup je to, čo zaznamenáva webový server, a môže to byť preložená adresa niekoľko skokov ďaleko.

Vyhľadanie verejnej IP odpovedá len na poslednú otázku. Nemôže vám povedať, na ktorú lokálnu adresu sa má preposielač naviazať, pretože jeden verejný výstup môže skrývať viacero interných zdrojov. Prečítajte adresu od toho, kto vlastní spojenie: z výstupu stavu klienta, zo samotného rozhrania alebo z priestoru názvov, kde tunel žije. Zobrať prvé rozhranie, ktorého názov vyzerá ako tunel, dá nesprávnu odpoveď, len čo existuje druhý profil.

Usporiadania kontajnerov a priestorov názvov potichu boria tento predpoklad. Preposielač v jednom sieťovom priestore názvov sa nemôže naviazať na tunel, ktorý existuje v inom, a žiadne množstvo úprav konfigurácie to nespraví.

Štyri kontroly predtým, než čokoľvek upravíte

Prejdite ich v poradí. Prvá kontrola, ktorá zlyhá, je miesto, kde sa zastavíte, pretože neskoršie predpokladajú, že skoršie platia.

1. Potvrďte, že používaný tunel je profil, okolo ktorého bolo proxy postavené, nie druhý profil, ktorý sa pripojil sám.
2. Vypíšte adresu, ktorá je práve na tom zariadení, a porovnajte ju s adresou v bežiacej konfigurácii.
3. Opýtajte sa preposielača, aký zdroj zistil, a nie čo tvrdí súbor na disku.
4. Potvrďte, že prevádzka z preposielača skutočne podlieha smerovacej a firewallovej politike, ktorú očakávate.

Adresa zariadenia je jednoduchá: ip -4 addr show dev tun0 vypíše aktuálnu a ip -4 route get 1.1.1.1 ukáže, ktoré rozhranie by jadro pre ten cieľ zvolilo. Preposielač, ktorý naviaže presnú adresu, hlasno zlyhá, keď adresa zmizne. Preposielač, ktorý naviaže zariadenie alebo sa vráti k predvolenému zdroju, ďalej funguje a uniká, a to je tichý výsledok.

Zladiť dokumentáciu s vydaním, ktoré prevádzkujete, nie s prvým výsledkom hľadania. Smernica odchádzajúcej adresy Squid je dokumentovaná pre v7 a staršie a dokumentácia v8 výslovne uvádza, že tam smernica nie je dostupná, takže skript postavený okolo nej túto hranicu neprežije (pozrite referenciu Squid tcp_outgoing_address). Overte vlastným parserom produktu, než sa čokoľvek znova načíta: squid -k parse hlási chyby a skončí bez toho, aby sa dotkol bežiaceho procesu.

Číslujte každý tunel a zahadzujte zastarané výmeny

Opätovné pripojenie je odovzdanie a odovzdanie potrebuje poriadok. Označte každé pozorované spojenie počítadlom alebo časovou pečiatkou, ktorá rastie pri každom úspešnom nadviazaní, a potom toto označenie preneste do konfigurácie kandidáta. Keď je označenie kandidáta staršie ako aktuálne, kandidáta zahoďte namiesto jeho použitia, pretože pomalá aktualizácia napísaná pre predchádzajúci tunel by inak prepísala nastavenia aktuálneho. Spájajte nárazy udalostí, aby blikajúce spojenie vytvorilo jeden prechod namiesto pätnástich.

Zoraďte prácu do štyroch krokov: zrušte platnosť starého výstupného stavu, počkajte, kým vlastník spojenia nahlási dokončenie, zostavte len spravovaný fragment, potom overte a aktivujte cez správcu služieb. Opätovné generovanie celého súboru z dvoch hodnôt adresy je spôsob, akým obmedzenia poslucháča, autentifikácia a politika cieľa potichu miznú. Rešpektujte aj úmyselné zastavenie. Pomocník, ktorý naďalej vytáča tunel, ktorý používateľ vypol, je chyba, nie odolnosť.

Otvorené sockety nebudú nasledovať novú adresu

Rekonfigurácia preposielača nehovorí nič o už nadviazaných spojeniach. Či sa vyprázdnia alebo zomrú, závisí od produktu, preto správanie pozorujte, namiesto toho, aby ste ho predpokladali.

Požiadavka obsluhovaná cez socket otvorený pred výmenou stále vychádza starou cestou, aj keď je nová konfigurácia správna. Ak na tom záleží, rozhodnite výslovne: povoľte krátke okno vyprázdnenia a prestaňte prijímať novú prácu, alebo ukončite staré sockety a prijmite chyby. Potom testujte novým spojením a tento výsledok držte oddelene od kontroly vyprázdnenia. Naviazanie na zdroj tiež nie je bezpečnostná hranica. Keď sa prevádzka nikdy nesmie dotknúť obvyklej trasy, vynúťte to značkami a pravidlami firewallu vrátane DNS a IPv6, aby neúspešné načítanie nechalo proxy výslovne vypnuté, nie otvorené.

Dokážte nový výstup čerstvou požiadavkou

Dôležitá je požiadavka otvorená po aktivácii, nie ping a nie už nacachovaná stránka. Požiadajte proxy o skutočnú URL a prečítajte výstupnú adresu, ktorú hlási vzdialená strana, a potom ju porovnajte s vlastným pohľadom klienta na tunel, keď ho poskytovateľ zobrazuje.

Držte parsovanie, opätovné načítanie a požiadavku ako samostatné príkazy, aby porucha ukázala na jediný krok. Prvé dve pri zlyhaní nič nezmenia, a práve preto bežia pred reštartom.

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

Ak opätovné načítanie zlyhá, zastavte službu a opravte fragment; proxy obsluhujúce so zastaraným výstupom je horšie než krátky výpadok. Ak načítanie uspeje, ale čerstvá požiadavka stále vychádza niekde nečakane, vráťte sa ku kontrole smerovania namiesto ďalšej úpravy adries. Zapíšte generáciu tunela, voči ktorej ste overovali, aby ďalšie opätovné pripojenie malo čo konkrétne porovnávať.