VPN включен, а localhost не работи: име, прокси или обвързване?

Сървърът ви за разработка отговори преди минута, а сега, когато тунелът е вдигнат, заявката изтича с име на хост, което никога не сте въвеждали. Два механизма обясняват почти всеки случай и отвън изглеждат еднакви. Наставка за търсене превръща кратко име в корпоративно, докато прокси изпраща loopback трафик към хост, който не може да го достигне. Разделянето на двете струва една заявка и спестява правилото на защитната стена, което щяхте да напишете.

Когато localhost се резолвва в корпоративната зона

Проверете в какво се резолвва името, докато тунелът е вдигнат, после изпълнете същата заявка без него и сравнете двата отговора. Издайникът е адрес в корпоративния диапазон там, където сте очаквали 127.0.0.1. Запис като localhost.mycompany.corp надделява над loopback записа, щом клиентът добави тази наставка към списъка за търсене, и заявката пътува до частен хост, където нищо не слуша на този порт. Четете списъка за търсене, вместо да гадаете, защото клиентът може да добави повече от един домейн и редът решава кой кандидат се пробва пръв:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Заменете името на хоста с буквалния адрес в приложението, клиента за база данни или URL на бележника, после повторете заявката. Ако отказът изчезне, имахте проблем с именуването и тунелът беше само спусъкът. Ако остане, слушателят или маршрутът е следващият заподозрян, а името беше просто подвеждаща следа.

Прокси настройки, които прихващат loopback

Системно прокси, приложено при вдигане на тунела, ще приеме заявка към 127.0.0.1 и ще я препрати към отдалечено прокси, което няма представа какво сте имали предвид. Празен списък за заобикаляне превръща локална заявка в отдалечена и съобщението за грешка рядко го казва. Добавете loopback адресите към списъка за заобикаляне за цялата сесия, а не за една команда, после потвърдете, че инструментът го спазва, преди да заключите нещо за мрежата.

Рамките за приложения четат собствените си променливи на средата, а понякога и собствения си конфигурационен файл, така че заобикаляне, което работи за един инструмент, не доказва нищо за следващия. Браузърите добавят особеност: браузърите на Chromium заобикалят проксито за loopback неявно и токен за заобикаляне може да премахне това поведение. Проверете действителното решение за проксито, вместо да предполагате, че настройката на операционната система е цялата история. Две команди решават въпроса за всичко, стартирано от shell:

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

Адресът на обвързване решава кой може да се свърже

Сървър, стартиран на 127.0.0.1, приема връзки само от тази машина, което обикновено е правилната настройка по подразбиране за разработка. Сървър на 0.0.0.0 отговаря на всеки интерфейс, включително VPN адаптера, което е по-голяма експозиция, отколкото повечето хора целят. Когато буквалният loopback адрес се провали, проверете обвързването преди всичко друго.

Погледнете слушащия сокет и отбележете адреса, към който е обвързан, не само порта. Ако друго устройство или контейнер трябва да достигне услугата през тунела, обвържете към конкретния интерфейс, който ще използва, и разрешете този порт умишлено. Ако само вашата машина се нуждае от нея, запазете тясното обвързване и оправете клиента, вместо да разширявате сървъра. Пренасочване на порт или слой тунели може да свърже двете, но всяко добавя компонент, който по-късно ще иска собствено отстраняване на проблеми.

Къде инструмент за отстраняване на грешки очаква LAN

Инструментите за отстраняване на грешки носят допускания, които тунелът тихо чупи. Мостът за отстраняване на грешки на телефон губи устройството си, когато VPN улови подмрежата на устройството, затова повторното свързване през LAN адрес или кабел избягва конфликта. Хъб за автоматизация на браузър изтича, когато хъбът е достъпен само през проксито или когато локална защитна стена изпусне контролния му порт. Отдалечен дебъгер може да изиска повишаване на права и loopback адрес там, където клиентът е пренаписал маршрута.

Определете контролния порт и порта за данни поотделно, защото единият често оцелява, докато другият не. После решете дали поправката принадлежи на конфигурацията на инструмента, на маршрут за тази подмрежа или на правило за разделен тунел. Редактирането на hosts файл на всяка машина на разработчик се мащабира най-зле и се забравя първо. Предпочитайте настройката, която живее с профила и може да бъде прегледана от този, който притежава тунела.

Спрете на първия етап, който се провали

Минете през три етапа: резолвнете името, отворете сокет към буквалния адрес, после оставете инструмента да направи своята връзка. Всеки етап премахва един слой, така че първият отказ назовава слоя за поправка и всичко след него остава непроверено. Запишете резултата, преди да промените нещо, защото поправка, приложена преди измерването, не може да се различи от късмет. Ако първият опит се провали, а повторен работи, тунелът вероятно не е бил готов, когато инструментът е стартирал.

Заменете фиксираното изчакване с ограничена проверка за готовност, която чака маршрута, и запазете неуспешния етап в журнала, за да види следващият човек къде е спряло. Инструмент, който се възстановява сам, не е поправен, той е късметлия и късметът свършва на чужда машина. Променяйте тунела последен и само за етапа, който наистина се е провалил. Този ред е и най-краткият път обратно към работеща компилация, защото ви спира да преправяте компонент, който никога не е участвал.