Proxy steeds op die ou tonneladres ná 'n VPN-herverbinding?
'n Herverbinding kan jou deurstuurder op 'n adres laat bind wat die tonnel nie meer besit nie. Vier geordende kontroles, 'n genommerde oorhandiging en 'n werklike toetsversoek.
Herbegin van die VPN-kliënt bewys net dat die tonnel terug is. Dit sê niks oor die proxy wat opdrag gekry het om daardeur uit te gaan nie. Squid, tinyproxy en die meeste ander deurstuurders hou die plaaslike bronadres wat hulle by die opstart verkry het, totdat iets hulle dwing om te herlaai. Wanneer 'n herverbinding 'n nuwe tonneladres uitdeel, misluk elke uitgaande verbinding by die deurstuurder, of hy begin deur jou gewone roete uitgaan.
Daardie tweede fout is die gevaarlike een: die tonnel is op, bladsye laai, en net die uitgangsadres is verkeerd.
Begin by die luisteraar, nie by die tonnel nie
Drie adresse speel 'n rol, en 'n herverbinding skuif net sommige daarvan. Die luisteraar is waar jou blaaier na wys, gewoonlik 127.0.0.1 of 'n LAN-adres, en dit gee nie om dat die tonnel verander het nie. Die uitgaande plaaslike bron is wat die deurstuurder die kern vra om te gebruik wanneer hy die volgende hop skakel, en dit is aan die tonneltoestel gebind. Die publieke uitgang is wat 'n webbediener log, en dit kan 'n vertaalde adres wees etlike hope verder.
'n Opsoek van die publieke IP beantwoord net die laaste vraag. Dit kan jou nie sê watter plaaslike adres 'n deurstuurder moet bind nie, want een publieke uitgang kan verskeie interne bronne verberg. Lees die adres by wie die verbinding besit: die kliënt se statusuitvoer, die koppelvlak self, of die naamruimte waar die tonnel leef. Om die eerste koppelvlak te gryp wie se naam soos 'n tonnel lyk, gee die verkeerde antwoord sodra 'n tweede profiel bestaan.
Houer- en naamruimte-uitlegte breek die aanname stilweg. 'n Deurstuurder in een netwerknaamruimte kan nie 'n tonnel bind wat in 'n ander bestaan nie, en geen hoeveelheid konfigurasiewysiging herstel dit nie.
Vier kontroles voordat jy enigiets wysig
Werk hierdie in volgorde deur. Die eerste kontrole wat misluk, is waar jy stop, want die latere aanvaar dat die vroeëre geld.
- Bevestig dat die tonnel in gebruik die profiel is waarom die proxy gebou is, nie 'n tweede profiel wat op sy eie gekoppel het nie.
- Druk die adres wat tans op daardie toestel is en vergelyk dit met die adres in die lopende konfigurasie.
- Vra die deurstuurder watter bron hy opgelos het, eerder as wat die lêer op skyf beweer.
- Bevestig dat verkeer van die deurstuurder werklik onderhewig is aan die roetering- en brandmuurbeleid wat jy verwag.
Die toesteladres is maklik: ip -4 addr show dev tun0 druk die huidige een, en ip -4 route get 1.1.1.1 wys watter koppelvlak die kern vir daardie bestemming sou kies. 'n Deurstuurder wat 'n presiese adres bind, misluk hardop wanneer die adres verdwyn. 'n Deurstuurder wat 'n toestel bind, of na die verstekbron terugval, bly werk en lek, en dit is die stille uitkoms.
Pas die dokumentasie by die weergawe wat jy gebruik, nie by die boonste soekresultaat nie. Squid se uitgaande-adres-richtlijn word vir v7 en vroeër gedokumenteer, en die v8-dokumentasie sê duidelik dat die richtlijn daar nie beskikbaar is nie, so 'n skrip wat daarom gebou is, oorleef nie daardie grens nie (sien die Squid tcp_outgoing_address-verwysing). Valideer met die produk se eie ontleder voordat enigiets herlaai word: squid -k parse rapporteer foute en sluit af sonder om die lopende proses te raak.
Nommer elke tonnel en verwerp verouderde omruilings
'n Herverbinding is 'n oorhandiging, en oorhandigings het 'n orde nodig. Merk elke waargenome verbinding met 'n teller of tydstempel wat by elke suksesvolle vestiging toeneem, en dra daardie merker in die kandidaatkonfigurasie. Wanneer die merker op 'n kandidaat ouer is as die huidige, laat val die kandidaat in plaas daarvan om dit toe te pas, want 'n stadige opdatering wat vir die vorige tonnel geskryf is, sal andersins die instellings vir die huidige een oorskryf. Smelt uitbarstings van gebeurtenisse saam sodat 'n wapperende skakel een oorgang lewer eerder as vyftien.
Rangskik die werk in vier bewegings: maak die ou uitgangstoestand ongeldig, wag tot die verbindingseienaar voltooiing rapporteer, bou net die bestuurde fragment, valideer en aktiveer dan deur die diensbestuurder. Om die hele lêer uit twee adreswaardes te hergenereer, is hoe luisteraarbeperkings, verifikasie en bestemmingsbeleid stilweg verdwyn. Respekteer ook 'n doelbewuste stop. 'n Helper wat aanhou om 'n tonnel te skakel wat die gebruiker afgesit het, is 'n fout, nie veerkragtigheid nie.
Oop sokkels sal nie die nuwe adres volg nie
Om die deurstuurder te herkonfigureer sê niks oor verbindings wat reeds gevestig is nie. Of hulle dreineer of sterf, hang van die produk af, so waarneem die gedrag eerder as om dit te aanvaar.
'n Versoek wat oor 'n sokkel bedien word wat voor die omruiling oopgemaak is, gaan steeds deur die ou pad uit, selfs wanneer die nuwe konfigurasie korrek is. As dit saak maak, besluit eksplisiet: laat 'n kort dreineervenster toe en stop om nuwe werk in te laat, of beëindig die ou sokkels en aanvaar die foute. Toets dan met 'n vars verbinding en hou daardie resultaat apart van die dreineerkontrole. Bronbinding is ook nie 'n sekuriteitsgrens nie. Wanneer verkeer nooit die gewone roete mag raak nie, dwing dit af met merke en brandmuurreëls, DNS en IPv6 ingesluit, sodat 'n mislukte herlaai die proxy eksplisiet af laat in plaas van oop.
Bewys die nuwe uitgang met 'n vars versoek
Wat saak maak, is 'n versoek wat ná aktivering oopgemaak is, nie 'n ping en nie 'n bladsy wat reeds gekas is nie. Vra die proxy vir 'n regte URL en lees die uitgangsadres wat die ander kant rapporteer, en vergelyk dit dan met die kliënt se eie siening van die tonnel wanneer die verskaffer een blootstel.
Hou die ontleding, die herlaai en die versoek as aparte opdragte sodat 'n fout na 'n enkele stap wys. Die eerste twee verander niks wanneer hulle misluk nie, en dit is juis waarom hulle voor die herbegin loop.
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.comAs die herlaai misluk, stop die diens en herstel die fragment; 'n proxy wat met verouderde uitgang bedien, is slegter as 'n kort onderbreking. As die herlaai slaag maar die vars versoek steeds op 'n onverwagte plek uitgaan, gaan terug na die roeteringkontrole in plaas daarvan om weer adresse te wysig. Teken die tonnelgenerasie aan waarteen jy gevalideer het, sodat die volgende herverbinding iets konkreets het om mee te vergelyk.