A proxy még mindig a régi alagútcímen van VPN-újracsatlakozás után?

A VPN-kliens újraindítása csak azt bizonyítja, hogy az alagút visszatért. Semmit sem mond arról a proxyról, amelynek azt mondták, hogy rajta keresztül lépjen ki. A Squid, a tinyproxy és a legtöbb más továbbító megtartja az indításkor feloldott helyi forráscímet, amíg valami újratöltésre nem kényszeríti őket. Amikor az újracsatlakozás új alagútcímet oszt ki, a továbbító vagy minden kimenő kapcsolatnál meghiúsul, vagy elkezd a szokásos útvonaladon keresztül kijutni.

A második hiba a veszélyes: az alagút áll, az oldalak betöltődnek, és csak a kimeneti cím rossz.

A figyelővel kezdd, ne az alagúttal

Három cím van játékban, és az újracsatlakozás csak néhányat mozgat közülük. A figyelő az, ahová a böngésződ mutat, általában 127.0.0.1 vagy egy LAN-cím, és nem érdekli, hogy az alagút megváltozott. A kimenő helyi forrás az, amit a továbbító a kerneltől kér a következő ugrás tárcsázásakor, és az alagúteszközhöz van kötve. A nyilvános kimenet az, amit egy webszerver naplóz, és lehet több ugrással arrébb lévő lefordított cím.

A nyilvános IP-keresés csak az utolsó kérdésre válaszol. Nem tudja megmondani, melyik helyi címhez kell a továbbítónak kötődnie, mert egy nyilvános kimenet több belső forrást rejthet. Olvasd a címet attól, akié a kapcsolat: a kliens állapotkimenetéből, magából az interfészből vagy abból a névtérből, ahol az alagút él. Az első alagútszerű nevű interfész megragadása rossz választ ad, amint létezik egy második profil.

A konténer- és névtér-elrendezések csendesen törik meg ezt a feltevést. Egy hálózati névtérben lévő továbbító nem tud olyan alagúthoz kötődni, amely egy másikban létezik, és semmilyen konfigurációszerkesztés nem javítja ezt.

Négy ellenőrzés, mielőtt bármit szerkesztenél

Sorrendben haladj végig rajtuk. Az első ellenőrzés, amely meghiúsul, az a pont, ahol megállsz, mert a későbbiek feltételezik, hogy a korábbiak érvényesek.

1. Erősítsd meg, hogy a használt alagút az a profil, amely köré a proxy épült, nem pedig egy második profil, amely magától csatlakozott.
2. Írd ki az adott eszközön jelenleg lévő címet, és hasonlítsd össze a futó konfigurációban lévő címmel.
3. Kérdezd meg a továbbítót, melyik forrást oldotta fel, ahelyett hogy mit állít a lemezen lévő fájl.
4. Erősítsd meg, hogy a továbbító forgalma valóban az általad várt útválasztási és tűzfal-szabályzat alá tartozik.

Az eszköz címe egyszerű: ip -4 addr show dev tun0 kiírja az aktuálisat, és ip -4 route get 1.1.1.1 megmutatja, melyik interfészt választaná a kernel ehhez a célhoz. A pontos címhez kötődő továbbító hangosan meghiúsul, amikor a cím eltűnik. Az eszközhöz kötődő vagy az alapértelmezett forrásra visszaeső továbbító tovább működik és szivárog, és ez a csendes kimenet.

A dokumentációt ahhoz a kiadáshoz igazítsd, amelyet futtatsz, ne a legfelső találathoz. A Squid kimenőcím-direktívája a v7 és korábbi verziókra van dokumentálva, a v8 dokumentációja pedig egyértelműen kimondja, hogy a direktíva ott nem érhető el, így a köré épített szkript nem éli túl ezt a határt (lásd a Squid tcp_outgoing_address referenciát). A termék saját elemzőjével ellenőrizd, mielőtt bármit újratöltenének: squid -k parse hibákat jelent, és kilép anélkül, hogy hozzányúlna a futó folyamathoz.

Számozd meg minden alagutat, és dobd el az elavult cseréket

Az újracsatlakozás átadás, az átadásoknak pedig sorrend kell. Jelöld meg minden megfigyelt kapcsolatot egy számlálóval vagy időbélyeggel, amely minden sikeres létrehozásnál nő, majd vidd azt a jelölést a jelölt konfigurációba. Ha egy jelölt jelölése régebbi a jelenleginél, dobd el a jelöltet ahelyett hogy alkalmaznád, mert az előző alagúthoz írt lassú frissítés egyébként felülírná a jelenlegi beállításait. Vond össze az események sorozatait, hogy a lengő kapcsolat egy átmenetet adjon tizenöt helyett.

Rendezd a munkát négy lépésbe: érvénytelenítsd a régi kimeneti állapotot, várd meg, amíg a kapcsolat tulajdonosa befejezést jelent, csak a kezelt töredéket építsd fel, majd ellenőrizz és aktiválj a szolgáltatáskezelőn keresztül. A teljes fájl két címértékből való újragenerálása az az út, amelyen a figyelő korlátozásai, a hitelesítés és a célpolitika csendesen eltűnnek. Tiszteld a szándékos leállítást is. Az a segéd, amely tovább tárcsáz egy alagutat, amelyet a felhasználó kikapcsolt, hiba, nem ellenálló képesség.

A nyitott socketek nem követik az új címet

A továbbító újrakonfigurálása semmit sem mond a már létrehozott kapcsolatokról. Hogy kiürülnek-e vagy meghalnak, a terméktől függ, ezért figyeld meg a viselkedést ahelyett hogy feltételeznéd.

A csere előtt megnyitott socketen kiszolgált kérés továbbra is a régi úton lép ki, akkor is, ha az új konfiguráció helyes. Ha ez számít, dönts egyértelműen: engedj rövid kiürítési ablakot, és ne fogadj új munkát, vagy zárd le a régi socketeket, és fogadd el a hibákat. Utána friss kapcsolattal tesztelj, és tartsd azt az eredményt külön a kiürítési ellenőrzéstől. A forráshoz kötés sem biztonsági határ. Amikor a forgalom soha nem érintheti a szokásos útvonalat, kényszerítsd ki jelölésekkel és tűzfalszabályokkal, a DNS-t és az IPv6-ot is beleértve, hogy a sikertelen újratöltés inkább kifejezetten leállítva hagyja a proxyt, mint nyitva.

Bizonyítsd az új kimenetet friss kéréssel

Az számít, hogy a kérés az aktiválás után nyíljon meg, nem egy ping és nem egy már gyorsítótárazott oldal. Kérj a proxytól valódi URL-t, és olvasd ki a távoli vég által jelentett kimeneti címet, majd hasonlítsd össze a kliens saját alagútképével, amikor a szolgáltató mutat egyet.

Tartsd az elemzést, az újratöltést és a kérést külön parancsokként, hogy a hiba egyetlen lépésre mutasson. Az első kettő nem változtat semmit, amikor meghiúsul, és éppen ezért futnak az újraindítás előtt.

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

Ha az újratöltés meghiúsul, állítsd le a szolgáltatást, és javítsd a töredéket; az elavult kimenettel kiszolgáló proxy rosszabb egy rövid kimaradásnál. Ha az újratöltés sikerül, de a friss kérés mégis valahol váratlanul lép ki, térj vissza az útválasztási ellenőrzéshez ahelyett hogy újra címeket szerkesztenél. Jegyezd fel az alagútgenerációt, amely ellen ellenőriztél, hogy a következő újracsatlakozásnak legyen mihez konkrétan hasonlítania.