Váš vývojový server odpověděl před minutou, a teď, když je tunel nahoře, požadavek vyprší s názvem hostitele, který jste nikdy nenapsali. Dva mechanismy vysvětlují téměř každý případ a zvenčí vypadají stejně. Přípona hledání promění krátké jméno na firemní, zatímco proxy posílá loopback provoz na hostitele, který ho nedokáže dosáhnout. Rozlišení těchto dvou věcí stojí jeden dotaz a ušetří pravidlo firewallu, které jste se chystali napsat.

Když se localhost přeloží do firemní zóny

Zkontrolujte, na co se jméno přeloží, když je tunel nahoře, pak spusťte stejný dotaz s tunelem dole a porovnejte obě odpovědi. Prozradí to adresa ve firemním rozsahu tam, kde jste čekali 127.0.0.1. Záznam jako localhost.mycompany.corp převáží nad loopback položkou, jakmile klient přidá tuto příponu do seznamu hledání, a požadavek putuje na soukromého hostitele, kde na tom portu nic neposlouchá. Čtěte seznam hledání, místo abyste hádali, protože klient může přidat víc než jednu doménu a pořadí rozhoduje, který kandidát se zkouší první:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Nahraďte název hostitele doslovnou adresou v aplikaci, v databázovém klientovi nebo v URL poznámkového bloku a potom požadavek zopakujte. Pokud selhání zmizí, měli jste problém s pojmenováním a tunel byl jen spouštěč. Pokud přetrvá, dalším podezřelým je naslouchající proces nebo trasa a jméno byla falešná stopa.

Nastavení proxy, které zachytí loopback

Systémová proxy uplatněná při zapnutí tunelu přijme požadavek na 127.0.0.1 a předá ho vzdálené proxy, která netuší, co jste mysleli. Prázdný seznam výjimek promění místní požadavek na vzdálený a chybová zpráva to málokdy řekne. Přidejte loopback adresy do seznamu výjimek pro celou relaci, ne pro jediný příkaz, a pak potvrďte, že to nástroj respektuje, než cokoli uzavřete o síti.

Aplikační frameworky čtou vlastní proměnné prostředí a někdy i vlastní konfigurační soubor, takže výjimka, která funguje pro jeden nástroj, nic nedokazuje pro další. Prohlížeče přidávají drobnost: prohlížeče založené na Chromiu obcházejí proxy pro loopback implicitně a token výjimky může toto chování odebrat. Zkontrolujte skutečné rozhodnutí proxy, místo abyste předpokládali, že nastavení operačního systému je celý příběh. Dva příkazy to vyřeší pro cokoli spuštěného z shellu:

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

Adresa bind rozhoduje, kdo se může připojit

Server spuštěný na 127.0.0.1 přijímá připojení jen z toho stroje, což je obvykle správné výchozí nastavení pro vývoj. Server na 0.0.0.0 odpovídá na každém rozhraní včetně adaptéru VPN, což je větší expozice, než většina lidí zamýšlí. Když doslovná loopback adresa nefunguje, zkontrolujte nejdřív bind.

Podívejte se na naslouchající socket a všimněte si adresy, na kterou je navázaný, ne jen portu. Pokud se má jiné zařízení nebo kontejner dostat ke službě přes tunel, naváže se na konkrétní rozhraní, které použije, a ten port vědomě povolte. Pokud ji potřebuje jen váš stroj, ponechte úzký bind a opravte klienta, místo abyste rozšiřovali server. Přesměrování portu nebo vrstva tunelů může obojí propojit, ale každá přidává komponentu, která bude později potřebovat vlastní ladění.

Kde ladicí nástroj očekává LAN

Ladicí nástroje nesou předpoklady, které tunel tiše rozbije. Most pro ladění telefonu ztratí zařízení, když VPN zachytí podsíť zařízení, takže opětovné připojení přes LAN adresu nebo kabel se konfliktu vyhne. Centrum pro automatizaci prohlížeče vyprší, když je centrum dostupné jen přes proxy, nebo když místní firewall zahodí jeho řídicí port. Vzdálený debugger může vyžadovat elevaci a loopback adresu tam, kde klient přepsal trasu.

Určete řídicí port a datový port odděleně, protože jeden často přežije, zatímco druhý ne. Pak rozhodněte, zda oprava patří do konfigurace nástroje, do trasy pro tuto podsíť, nebo do pravidla rozděleného tunelu. Úprava souboru hosts na každém vývojářském stroji škáluje nejhůř a zapomene se první. Dejte přednost nastavení, které žije s profilem a může ho zkontrolovat ten, komu tunel patří.

Zastavte se u první etapy, která selže

Projděte tři etapy: přeložte jméno, otevřete socket na doslovnou adresu a pak nechte nástroj vytvořit vlastní připojení. Každá etapa odstraní jednu vrstvu, takže první selhání pojmenuje vrstvu k opravě a všechno po něm zůstane neotestované. Napište výsledek, než cokoli změníte, protože opravu použitou před měřením nelze odlišit od štěstí. Pokud první pokus selže a opakování funguje, tunel pravděpodobně nebyl připravený, když nástroj startoval.

Nahraďte pevné čekání omezenou kontrolou připravenosti, která čeká na trasu, a ponechte selhávající etapu v logu, aby další člověk viděl, kde se to zastavilo. Nástroj, který se sám zotaví, není opravený, má štěstí, a štěstí dojde na cizím stroji. Tunel měňte naposledy a jen pro etapu, která skutečně selhala. Toto pořadí je také nejkratší cesta zpět k funkčnímu sestavení, protože vás zastaví před přestavbou komponenty, která nikdy nebyla zapojena.

Související články