Барањата на апликацијата паѓаат зад корпоративен VPN, но прелистувачот работи

Ја отворате внатрешната порта во прелистувач и таа се вчитува. Ја стартувате апликацијата што го повикува истиот домаќин и таа паѓа, со порака што не именува ниту еден слој. Тунелот го носи прелистувачот, така што тунелот не е првиот осомничен. Четири работи стојат меѓу вашето барање и услугата, и секоја остава различен отпечаток. Ова е редот што го следам, почнувајќи од барањето што апликацијата навистина го испраќа, а не од страницата со поставки на VPN клиентот.

Погледнете го барањето што апликацијата навистина го испраќа

Пред да ја допрете конфигурацијата, нека апликацијата ви каже што прави. Снимање на едно барање со проксито експлицитно исклучено и едноставен тест на порта ви даваат две основни линии со кои се споредуваат следните чекори. Ако барањето помине со исклучено прокси, веќе сте завршиле три од четирите слоја.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

Извршете ги последните две кон истата дестинација и гледајте каде се разидуваат. Прелистувач што работи плус curl што работи плус апликација што не работи го стеснуваат проблемот на нешто што апликацијата го додава: прокси, транспорт или големина на порака.

Апликацијата наследи прокси што никој не го постави

Повеќето HTTP стекови ја читаат конфигурацијата за прокси од оперативниот систем по стандард. Корпоративниот VPN клиент често инсталира едно како дел од својот профил за пристап, така што барањата излегуваат низ прокси што развивачот никогаш не го спомнал во кодот. Во .NET стандардниот обработувач влече од поставките на IE/WinHTTP; Java го чита -Dhttp.proxyHost; Node нема вградена поддршка за прокси додека библиотека не ја додаде. Неуспехот ретко е чисто одбивање, затоа луѓето почнуваат да го гледаат серверот.

Тестот чини едно барање: исклучете го проксито експлицитно на еден обработувач и споредете.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

Ако тоа помине, поправката припаѓа на конфигурацијата на апликацијата, а не на тунелот. Повторете ја ревизијата за секое извршно опкружување во проектот, бидејќи секое чита различен извор и само едно може да е расипано.

Портата што ја избравте не е портата што политиката ја дозволува

Рутиран домаќин не е дозволена услуга. Корпоративната политика обично дозволува излезни веб-порти и ги отфрла останатите, така што услуга на 8080 или 1883 е недостапна додека 443 работи добро. Прелистувачот овде ништо не докажува: тој по дефиниција користи 443.

Објавете ја истата услуга зад 443 и дојдете до неа по име пред да побарате исклучок. Ако исклучокот навистина е потребен, ограничете го на еден опсег извори и една дестинација и третирајте го како дел од дефиницијата на услугата, а не како нечие лично заобиколување.

Суров TCP што патеката го ресетира

Долготрајните сурови TCP конекции се слојот што паѓа најзбунувачки. Патека што дозволува веб сообраќај сепак може да ресетира или препише невообичаен излезен TCP, а клиентот пријавува грешка на сокет што се чита како прекин. Услугите за пораки и настани обично доставуваат WebSocket транспорт токму за таков вид мрежа, а префрлањето е опција на клиентот, а не промена на тунелот.

Сменете го транспортот, тестирајте повторно и не менувајте ништо друго во истото извршување. Тој тест со една променлива ви кажува дали ресетирањето дошло од патеката или од услугата.

Конекции што се затвораат само при големи товари

Барање што поминува и потоа умира околу секунда подоцна, но само кога телото е големо, укажува на ограничување на големината некаде во средината. Посредник што ги брои бајтите на пораките може да ја испушти конекцијата на средина од преносот, а клиентот пријавува абнормално затворање наместо истек на време.

Поделете го товарот на делови на апликациско ниво. Држете го тоа одделно од работата со MTU: намалувањето на големината на пакетот на тунелот помага кога обичните TCP сесии застануваат на постојан број бајти, а не прави ништо за порака што посредникот ја смета за преголема.

Како да ги различите четирите во еден премин

Три набљудувања решаваат повеќето случаи. Дали неуспехот се случува веднаш или само со големо тело? Дали истото барање поминува со исклучено прокси? Дали исходот се менува кога ја менувате портата или транспортот? Запишете ги одговорите пред следната промена, бидејќи корпоративен VPN плус наследено прокси плус стандардна поставка на апликацијата ви даваат три веројатни причини одеднаш.

Држете една променлива по тест и запишете го домаќинот на дестинацијата што сте го користеле. Без таа основна линија, следниот човек ги повторува сите четири чекори од почеток.