Artemis mund të anashkalojë SOCKS për një broker loopback
Kontrolloni destinacionin e brokerit dhe sjelljen e socksRemoteDNS kur një lidhje Artemis ka sukses pavarësisht kredencialeve SOCKS qëllimisht të gabuara.
Një lidhje me brokerin Artemis që ka sukses me fjalëkalimin e gabuar SOCKS mund të ketë anashkaluar trajtuesin e proxy-t. Kontrolloni destinacionin e brokerit, jo vetëm socksHost.
Dokumentacioni i transportit i përshkruan adresat e brokerit loopback si localhost dhe 127.0.0.1 si adresa që anashkalojnë konfigurimin SOCKS. Për rrugën normale të zgjidhjes lokale, përdorni adresën e synuar të brokerit jo-loopback kur lidhja duhet të kalojë përmes ndërmjetësit. Një alias tjetër që ende zgjidhet në loopback mund të japë të njëjtin rezultat.
Kontrolloni kushtin e saktë të versionit të connector-it
Kodi burimor më i ri i connector-it upstream përfshin një përjashtim të qartë remote-DNS. Kushti i trajtuesit të proxy-t është:
socksEnabled && (socksRemoteDNS || !isTargetLocalHost())
Kur socksRemoteDNS është aktivizuar në një implementim që përmban atë kusht, connector-i e lë destinacionin të pazgjidhur dhe instalon trajtuesin SOCKS edhe për një destinacion që duket si loopback. Me vlerën e paracaktuar të dokumentuar false, testi i adresës lokale vazhdon të ketë rëndësi.
Kjo ndryshon kuptimin e një emri hosti si localhost: kur i kalohet një serveri SOCKS për zgjidhje, i referohet pamjes së proxy-t për destinacionin. Konfirmoni se ky është vendndodhja e synuar e brokerit përpara se të zgjidhni zgjidhjen në distancë.
Përshtatni sjelljen me klientin Artemis të instaluar. Pasi trajtuesi të jetë vërtet në rrugë, dalloni vërtetimin SOCKS nga vërtetimi i brokerit dhe verifikoni rrugën e lidhjes që rezulton në vend që ta trajtoni një sesion të suksesshëm brokeri si provë që u përdorën kredencialet e proxy-t.