VPN bekapcsolva, a localhost nem működik: név, proxy vagy bind?

A fejlesztői kiszolgálója egy perce még válaszolt, most pedig, hogy az alagút felállt, a kérés egy olyan gazdagépnévvel fut időtúllépésbe, amelyet soha nem gépelt be. Szinte minden esetet két mechanizmus magyaráz, és kívülről ugyanúgy néznek ki. A keresési utótag rövid nevet vállalativá tesz, míg a proxy a loopback forgalmat olyan gazdagépre küldi, amely nem tudja elérni. A kettő szétválasztása egy lekérdezésbe kerül, és megspórolja a tűzfalszabályt, amelyet épp írni készült.

Amikor a localhost a vállalati zónába oldódik

Ellenőrizze, mire oldódik fel a név, amíg az alagút áll, majd futtassa ugyanezt a lekérdezést kikapcsolt alagúttal, és hasonlítsa össze a két választ. Az árulkodó jel egy cím a vállalati tartományban ott, ahol 127.0.0.1-t várt. Egy localhost.mycompany.corp-hez hasonló rekord legyőzi a loopback bejegyzést, amint a kliens hozzáadja ezt az utótagot a keresési listához, és a kérés egy privát gazdagépre utazik, ahol semmi sem figyel azon a porton. Olvassa el a keresési listát ahelyett, hogy találgatna, mert a kliens egynél több tartományt is hozzáadhat, és a sorrend dönti el, melyik jelöltet próbálja először:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Cserélje le a gazdagépnevet a szó szerinti címre az alkalmazásban, az adatbázis-kliensben vagy a jegyzetfüzet URL-jében, majd ismételje meg a kérést. Ha a hiba eltűnik, névfeloldási problémája volt, és az alagút csak a kiváltó ok volt. Ha megmarad, a figyelő vagy az útvonal a következő gyanúsított, és a név csak hamis nyom volt.

A loopbacket elfogó proxybeállítások

Az alagút felállásakor alkalmazott rendszerproxy elfogad egy kérést a 127.0.0.1 címre, és továbbítja egy távoli proxyhoz, amelynek fogalma sincs, mit akart. Az üres kivétellista helyi kérést tesz távolivá, és a hibaüzenet ezt ritkán mondja ki. Adja hozzá a loopback címeket a kivétellistához az egész munkamenetre, nem egyetlen parancsra, majd erősítse meg, hogy az eszköz tiszteletben tartja, mielőtt bármit megállapítana a hálózatról.

Az alkalmazáskeretrendszerek a saját környezeti változóikat és néha a saját konfigurációs fájlukat olvassák, így az egyik eszköznél működő kivétel semmit sem bizonyít a következőnél. A böngészők egy csavart adnak hozzá: a Chromium-alapú böngészők implicit módon megkerülik a proxyt loopback esetén, és egy kivételtoken eltávolíthatja ezt a viselkedést. Ellenőrizze a tényleges proxy-döntést ahelyett, hogy feltételezné, hogy az operációs rendszer beállítása a teljes történet. Két parancs eldönti ezt mindenre, amit shellből indítanak:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

A bind cím dönti el, ki csatlakozhat

A 127.0.0.1 címen induló kiszolgáló csak arról a gépről fogad kapcsolatokat, ami általában a helyes alapértelmezés fejlesztéshez. A 0.0.0.0 címen futó kiszolgáló minden interfészen válaszol, a VPN-adaptert is beleértve, ami nagyobb kitettség annál, mint amire a legtöbben gondolnak. Amikor a szó szerinti loopback cím meghiúsul, először a bindot ellenőrizze.

Nézze meg a figyelő socketet, és jegyezze fel a címet, amelyhez kötve van, ne csak a portot. Ha egy másik eszköznek vagy konténernek el kell érnie a szolgáltatást az alagúton keresztül, kösse ahhoz az interfészhez, amelyet használni fog, és tudatosan engedélyezze azt a portot. Ha csak a saját gépének kell, tartsa a szűk bindot, és a kiszolgáló szélesítése helyett javítsa a klienst. A porttovábbítás vagy egy alagútréteg összekötheti a kettőt, de mindegyik hozzáad egy komponenst, amelynek később saját hibakeresésre lesz szüksége.

Ahol egy hibakereső eszköz a LAN-t várja

A hibakereső eszközök olyan feltételezéseket hordoznak, amelyeket az alagút csendben megtör. A telefonos hibakereső híd elveszíti az eszközét, amikor a VPN elfogja az eszköz alhálózatát, ezért a LAN-címen vagy kábelen át történő újracsatlakozás elkerüli az ütközést. A böngészőautomatizálási hub időtúllépésbe fut, ha a hub csak a proxyn keresztül érhető el, vagy ha egy helyi tűzfal elejti a vezérlőportját. Egy távoli debugger emelést és loopback címet követelhet ott, ahol a kliens átírta az útvonalat.

A vezérlőportot és az adatportot külön azonosítsa, mert gyakran az egyik túléli, míg a másik nem. Ezután döntse el, hogy a javítás az eszköz konfigurációjába tartozik, az alhálózat útvonalába, vagy az osztott alagút szabályába. A hosts fájl szerkesztése minden fejlesztői gépen a legrosszabbul skálázódik, és először felejtődik el. Részesítse előnyben azt a beállítást, amely a profillal él, és amelyet az alagút tulajdonosa bármikor átnézhet.

Álljon meg az első meghiúsuló szakasznál

Három szakaszon haladjon végig: oldja fel a nevet, nyisson socketet a szó szerinti címre, majd engedje, hogy az eszköz saját kapcsolatot létesítsen. Minden szakasz egy réteget szüntet meg, így az első hiba megnevezi a javítandó réteget, és minden utána tesztelés nélkül marad. Írja le az eredményt, mielőtt bármit módosítana, mert a mérés előtt alkalmazott javítás nem különböztethető meg a szerencsétől. Ha az első kísérlet meghiúsul, és egy ismétlés működik, az alagút valószínűleg nem volt kész, amikor az eszköz elindult.

Cserélje le a rögzített várakozást az útvonalra váró korlátozott készültségi ellenőrzésre, és tartsa a meghiúsuló szakaszt a naplóban, hogy a következő ember lássa, hol állt meg. Az az eszköz, amely magától helyreáll, nincs megjavítva, csak szerencsés, és a szerencse valaki más gépén fogy el. Az alagutat utoljára módosítsa, és csak arra a szakaszra, amely valóban meghiúsult. Ez a sorrend egyben a legrövidebb út vissza egy működő buildez, mert megakadályozza, hogy újraépítsen egy komponenst, amely soha nem vett részt benne.