Vai starpniekserveris joprojām ir vecajā tuneļa adresē pēc VPN atkārtotas pievienošanas?

VPN klienta atkārtota palaišana pierāda tikai to, ka tunelis ir atgriezies. Tā neko nepasaka par starpniekserveri, kuram tika likts iziet caur to. Squid, tinyproxy un lielākā daļa citu pārsūtītāju tur vietējo avota adresi, ko tie noteica palaišanas laikā, līdz kaut kas liek tiem pārlādēties. Kad atkārtota pievienošana piešķir jaunu tuneļa adresi, pārsūtītājs vai nu neizdodas katrā izejošajā savienojumā, vai sāk iziet pa jūsu parasto maršrutu.

Otrā kļūda ir bīstamā: tunelis darbojas, lapas ielādējas, un nepareiza ir tikai izejas adrese.

Sāciet ar klausītāju, nevis tuneli

Spēlē ir trīs adreses, un atkārtota pievienošana pārvieto tikai dažas no tām. Klausītājs ir vieta, uz kuru norāda jūsu pārlūks, parasti 127.0.0.1 vai LAN adrese, un tam nav svarīgi, ka tunelis ir mainījies. Izejošais vietējais avots ir tas, ko pārsūtītājs lūdz kodolam izmantot, izvēloties nākamo lēcienu, un tas ir saistīts ar tuneļa ierīci. Publiskā izeja ir tas, ko reģistrē tīmekļa serveris, un tā var būt tulkota adrese vairāku lēcienu attālumā.

Publiskās IP meklēšana atbild tikai uz pēdējo jautājumu. Tā nevar pateikt, kurai vietējai adresei pārsūtītājam jāpiesaistās, jo viena publiskā izeja var slēpt vairākus iekšējos avotus. Lasiet adresi no tā, kam pieder savienojums: klienta statusa izvades, pašas saskarnes vai vārdu telpas, kurā dzīvo tunelis. Paņemot pirmo saskarni, kuras nosaukums izskatās kā tunelis, tiek iegūta nepareiza atbilde, tiklīdz pastāv otrs profils.

Konteinera un vārdu telpas izkārtojumi klusi salauž šo pieņēmumu. Pārsūtītājs vienā tīkla vārdu telpā nevar piesaistīties tunelim, kas pastāv citā, un nekāda konfigurācijas rediģēšana to nelabo.

Četras pārbaudes pirms kaut ko rediģējat

Veiciet tās secībā. Pirmā neizdevusies pārbaude ir vieta, kur apstājaties, jo vēlākās pieņem, ka iepriekšējās ir spēkā.

1. Pārliecinieties, ka izmantotais tunelis ir profils, ap kuru tika veidots starpniekserveris, nevis otrs profils, kas pievienojās pats.
2. Izdrukājiet adresi, kas šobrīd ir šajā ierīcē, un salīdziniet to ar adresi darbojošā konfigurācijā.
3. Jautājiet pārsūtītājam, kādu avotu tas noteica, nevis ko apgalvo faila diskā.
4. Pārliecinieties, ka pārsūtītāja plūsma patiešām ir pakļauta maršrutēšanas un ugunsmūra politikai, ko gaidāt.

Ierīces adrese ir vienkārša: ip -4 addr show dev tun0 izdrukā pašreizējo, bet ip -4 route get 1.1.1.1 parāda, kuru saskarni kodols izvēlētos šim galamērķim. Pārsūtītājs, kas piesaista precīzu adresi, skaļi neizdodas, kad adrese pazūd. Pārsūtītājs, kas piesaista ierīci vai atgriežas pie noklusējuma avota, turpina strādāt un noplūst, un tas ir klusais iznākums.

Saskaņojiet dokumentāciju ar izdevumu, ko izpildāt, nevis ar pirmo meklēšanas rezultātu. Squid izejošās adreses direktīva ir dokumentēta v7 un vecākām versijām, un v8 dokumentācija skaidri saka, ka direktīva tur nav pieejama, tāpēc uz to balstīts skripts neiztur šo robežu (skatiet Squid tcp_outgoing_address atsauci). Pārbaudiet ar paša produkta parsētāju, pirms kaut kas tiek pārlādēts: squid -k parse ziņo par kļūdām un iziet, neaizskarot darbojošos procesu.

Numurējiet katru tuneli un atmetiet novecojušas nomaiņas

Atkārtota pievienošana ir nodošana, un nodošanai vajadzīga secība. Atzīmējiet katru novēroto savienojumu ar skaitītāju vai laika zīmogu, kas pieaug pie katras veiksmīgas izveides, pēc tam pārnest to zīmi kandidāta konfigurācijā. Kad kandidāta zīme ir vecāka par pašreizējo, atmetiet kandidātu, nevis piemērojiet to, jo lēns atjauninājums, kas rakstīts iepriekšējam tunelim, citādi pārrakstīs pašreizējā iestatījumus. Apvienojiet notikumu uzliesmojumus, lai mirgojošs savienojums dotu vienu pāreju, nevis piecpadsmit.

Sakārtojiet darbu četros gājienos: anulējiet veco izejas stāvokli, nogaidiet, līdz savienojuma īpašnieks ziņo par pabeigšanu, izveidojiet tikai pārvaldīto fragmentu, pēc tam pārbaudiet un aktivizējiet caur pakalpojumu pārvaldnieku. Visa faila atkārtota ģenerēšana no divām adreses vērtībām ir veids, kā klusi pazūd klausītāja ierobežojumi, autentifikācija un galamērķa politika. Cieniet arī apzinātu apturēšanu. Palīgs, kas turpina zvanīt tunelim, kuru lietotājs izslēdza, ir kļūda, nevis noturība.

Atvērti ligzdas nesekos jaunajai adresei

Pārsūtītāja pārkonfigurēšana neko nepasaka par jau izveidotiem savienojumiem. Vai tie iztukšosies vai mirs, atkarīgs no produkta, tāpēc novērojiet uzvedību, nevis pieņemiet to.

Pieprasījums, kas apkalpots caur ligzdu, kura atvērta pirms nomaiņas, joprojām iziet pa veco ceļu, pat ja jaunā konfigurācija ir pareiza. Ja tas ir svarīgi, izlemiet skaidri: pieļaujiet īsu iztukšošanas logu un pārtrauciet pieņemt jaunu darbu, vai aizveriet vecās ligzdas un pieņemiet kļūdas. Pēc tam pārbaudiet ar jaunu savienojumu un turiet šo rezultātu atsevišķi no iztukšošanas pārbaudes. Avota piesaiste arī nav drošības robeža. Kad plūsma nekad nedrīkst skart parasto maršrutu, uzspiediet to ar atzīmēm un ugunsmūra noteikumiem, tostarp DNS un IPv6, lai neizdevusies pārlāde atstātu starpniekserveri skaidri izslēgtu, nevis atvērtu.

Pierādiet jauno izeju ar jaunu pieprasījumu

Svarīgi ir tas, ka pieprasījums tiek atvērts pēc aktivizācijas, nevis ping un nevis jau kešatmiņā esoša lapa. Palūdziet starpniekserverim īstu URL un nolasiet izejas adresi, ko ziņo tālā puse, pēc tam salīdziniet to ar klienta skatījumu uz tuneli, kad pakalpojumu sniedzējs to parāda.

Turiet parsēšanu, pārlādi un pieprasījumu kā atsevišķas komandas, lai kļūme norādītu uz vienu soli. Pirmās divas neko nemaina, kad tās neizdodas, un tieši tāpēc tās tiek izpildītas pirms atkārtotas palaišanas.

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

Ja pārlāde neizdodas, apturiet pakalpojumu un salabojiet fragmentu; starpniekserveris, kas darbojas ar novecojušu izeju, ir sliktāk nekā īss pārtraukums. Ja pārlāde izdodas, bet jaunais pieprasījums joprojām iziet kaut kur negaidīti, atgriezieties pie maršrutēšanas pārbaudes, nevis atkal rediģējiet adreses. Pierakstiet tuneļa paaudzi, pret kuru pārbaudījāt, lai nākamajai atkārtotajai pievienošanai būtu ko konkrēti salīdzināt.