Proxy je i dalje na staroj adresi tunela nakon ponovnog povezivanja VPN-a?

Ponovno pokretanje VPN klijenta dokazuje samo da se tunel vratio. O tome ne govori ništa o proxyju kojem je rečeno da izlazi kroz njega. Squid, tinyproxy i većina drugih prosljeđivača drže lokalnu izvornu adresu koju su odredili pri pokretanju dok ih nešto ne prisili na ponovno učitavanje. Kad ponovno povezivanje dodijeli novu adresu tunela, prosljeđivač ili pada na svakom odlaznom povezivanju, ili počinje izlaziti kroz vašu uobičajenu rutu.

Taj drugi kvar je opasan: tunel radi, stranice se učitavaju, a samo je izlazna adresa pogrešna.

Počnite od slušača, ne od tunela

U igri su tri adrese, a ponovno povezivanje pomjera samo neke od njih. Slušač je mjesto na koje pokazuje vaš preglednik, obično 127.0.0.1 ili LAN adresa, i njega ne zanima što se tunel promijenio. Odlazni lokalni izvor je ono što prosljeđivač traži od jezgre kad bira sljedeći hop, i on je vezan za uređaj tunela. Javni izlaz je ono što web poslužitelj bilježi, a to može biti prevedena adresa nekoliko hopova dalje.

Pretraga javne IP adrese odgovara samo na posljednje pitanje. Ne može vam reći na koju lokalnu adresu prosljeđivač treba da se veže, jer jedan javni izlaz može skrivati nekoliko unutrašnjih izvora. Pročitajte adresu od onoga koji posjeduje vezu: izlaza statusa klijenta, samog interfejsa ili imenskog prostora u kojem tunel živi. Uzimanje prvog interfejsa čije ime liči na tunel daje pogrešan odgovor čim postoji drugi profil.

Kontejnerski i imenski rasporedi tiho ruše tu pretpostavku. Prosljeđivač u jednom mrežnom imenskom prostoru ne može se vezati za tunel koji postoji u drugom, i nikakvo uređivanje konfiguracije to ne popravlja.

Četiri provjere prije nego što bilo šta uredite

Prođite kroz njih redom. Prva provjera koja padne je mjesto na kojem se zaustavljate, jer kasnije pretpostavljaju da ranije važe.

1. Potvrdite da je tunel u upotrebi profil oko kojeg je proxy izgrađen, a ne drugi profil koji se sam povezao.
2. Ispišite adresu koja je trenutno na tom uređaju i uporedite je s adresom u konfiguraciji koja radi.
3. Pitajte prosljeđivač koji je izvor odredio, a ne šta tvrdi datoteka na disku.
4. Potvrdite da promet s prosljeđivača zaista podliježe politici rutiranja i vatrozida koju očekujete.

Adresa uređaja je laka: ip -4 addr show dev tun0 ispisuje trenutnu, a ip -4 route get 1.1.1.1 pokazuje koji bi interfejs jezgra odabrala za to odredište. Prosljeđivač koji se veže za tačnu adresu glasno pada kad adresa nestane. Prosljeđivač koji se veže za uređaj ili se vraća na zadani izvor nastavlja raditi i curi, a to je tihi ishod.

Uskladite dokumentaciju s izdanjem koje pokrećete, a ne s prvim rezultatom pretrage. Squidova direktiva odlazne adrese dokumentirana je za v7 i ranije, a dokumentacija v8 izričito kaže da direktiva tamo nije dostupna, pa skripta izgrađena oko nje ne preživljava tu granicu (pogledajte Squid tcp_outgoing_address referencu). Provjerite vlastitim parserom proizvoda prije nego što se bilo šta ponovo učita: squid -k parse prijavljuje greške i izlazi ne dirajući proces koji radi.

Numerišite svaki tunel i odbacite zastarjele zamjene

Ponovno povezivanje je primopredaja, a primopredaje traže redoslijed. Označite svaku posmatranu vezu brojačem ili vremenskom oznakom koja raste pri svakom uspješnom uspostavljanju, pa tu oznaku nosite unutar kandidatske konfiguracije. Kad je oznaka na kandidatu starija od trenutne, odbacite kandidata umjesto da ga primijenite, jer će sporo ažuriranje napisano za prethodni tunel inače pregaziti postavke za trenutni. Spojite navale događaja tako da veza koja treperi proizvede jedan prijelaz umjesto petnaest.

Poredajte posao u četiri poteza: poništite staro stanje izlaza, sačekajte da vlasnik veze prijavi završetak, izgradite samo upravljani fragment, zatim provjerite i aktivirajte kroz upravitelja servisa. Ponovno generisanje cijele datoteke iz dvije vrijednosti adresa je način na koji ograničenja slušača, autentifikacija i politika odredišta tiho nestaju. Poštujte i namjerno zaustavljanje. Pomoćnik koji nastavlja birati tunel koji je korisnik isključio je greška, a ne otpornost.

Otvoreni socketi neće slijediti novu adresu

Rekonfigurisanje prosljeđivača ne govori ništa o vezama koje su već uspostavljene. Hoće li se isprazniti ili umrijeti zavisi od proizvoda, pa promatrajte ponašanje umjesto da ga pretpostavljate.

Zahtjev poslužen preko socketa otvorenog prije zamjene i dalje izlazi starim putem, čak i kad je nova konfiguracija ispravna. Ako je to važno, odlučite izričito: dopustite kratak prozor pražnjenja i prestanite primati novi posao, ili prekinite stare sockete i prihvatite greške. Zatim testirajte svježom vezom i držite taj rezultat odvojeno od provjere pražnjenja. Vezanje za izvor također nije sigurnosna granica. Kad promet nikada ne smije dotaknuti uobičajenu rutu, provedite to oznakama i pravilima vatrozida, uključujući DNS i IPv6, tako da neuspjelo učitavanje ostavi proxy izričito isključenim umjesto otvorenim.

Dokažite novi izlaz svježim zahtjevom

Važan je zahtjev otvoren nakon aktivacije, a ne ping i ne već keširana stranica. Zatražite od proxyja stvarni URL i pročitajte izlaznu adresu koju prijavljuje drugi kraj, pa je uporedite s vlastitim viđenjem tunela kod klijenta kad ga pružatelj izloži.

Držite parsiranje, ponovno učitavanje i zahtjev kao odvojene naredbe da kvar pokaže na jedan korak. Prve dvije ne mijenjaju ništa kad padnu, i upravo zato se izvode prije restarta.

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

Ako ponovno učitavanje padne, zaustavite servis i popravite fragment; proxy koji služi sa zastarjelim izlazom gori je od kratkog prekida. Ako ponovno učitavanje uspije ali svježi zahtjev i dalje izlazi negdje neočekivano, vratite se provjeri rutiranja umjesto da ponovo uređujete adrese. Zabilježite generaciju tunela prema kojoj ste provjeravali, da sljedeće ponovno povezivanje ima nešto konkretno za poređenje.