Dante SOCKS sur loopback por HTTPS-servo nur tra WireGuard

Ligi dediĉitan SOCKS-auskultanton al loopback kaj permesi unu TCP-celon. Tenu aparte la eliran fonton de Dante, la kernan itineron, DNS kaj la politikon pri tunela perdo.

Ĉi tiu manlibro donas al prokse-konscia aplikaĵo aliron al ekzistanta WireGuard-itinero sen publikigi proksan pordon sur la VPN-servilo aŭ en la interreto. La SOCKS-demono provizas la aplikaĵan interfacon, WireGuard provizas la jam aprobitan IP-itinieron, kaj neniu el ili aŭtentikigas la uzanton anstataŭ vi. Ĉiu paŝo sube produktas ion, kion vi povas inspekti, kaj ĉiu havas retroiron: haltigu la instancon, forigu la regulon aŭ forigu la proksagordon de la aplikaĵo. Nenio ĉi tie ŝanĝas la defaŭltan itineron de la gastiganto.

La ekzemplo supozas, ke Dante 1.4.x estas instalita kiel dediĉita, administrata instanco sur fidinda Linuksa laborejo, kun la pakaĵa servokonto kaj protokola agordo lasitaj surloke. La laborejo posedas 10.77.0.2 sur sia WireGuard-interfaco, atingas 10.60.0.20:443 tra tiu tunelo, kaj la propra nomo de la servo estas app.corp.example.

Paŝo 1: ligi la auskultanton nur al loopback

Metu la sekciojn pri reto, metodo kaj reguloj en la aktivan agordon de la instanco, anstataŭigante la ekzemplajn adresojn. Ĉiuj servilaj agordoj venas antaŭ la regulaj blokoj:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

Ĉi tio estas fragmento, ne anstataŭaĵo por la uzanto- kaj protokolaj agordoj de la pakaĵo. Elektu neuzatan lokan pordon kaj konfirmu, ke ĉi tiu dediĉita instanco havas neniujn aliajn auskultantojn, neniujn pli larĝajn pasregulojn kaj neniujn suprajn ĉenajn enskribojn, kiuj ŝanĝus la kontrakton. Se antaŭa agordo lasis socks pass sen cellimigo, forigu ĝin antaŭ ol testi ion ajn.

La retroiro por ĉi tiu paŝo estas haltigi la instancon; la agorda dosiero povas resti sur la disko dum vi restarigas ĝin.

Paŝo 2: skribu du regulojn, ne unu

La agorda referenco de Dante donas al la du regulaj tipoj malsamajn taskojn. La klienta regulo permesas konekton al la loopback-auskultanto, kaj ĝia celo estas la adreso de la auskultanto mem. La SOCKS-regulo permesas la petatan pluan konekton al la aprobita gastiganto kaj pordo. Neakordaj petoj estas blokataj defaŭlte, kaj tial mankanta regulo aspektas identa al rompita itinero.

Rimarku, kion ĉi tiu agordo intence ne faras: ĝi petas neniun SOCKS-pasvorton. Tio taŭgas por fidinda loka gastiganto, kaj ĝi ne estas uzantaŭtentikigo. Ajna alia procezo sur tiu maŝino ankaŭ povas uzi loopback. Konservu la propran aŭtentikigon de la fora aplikaĵo, kaj ne reuzu ĉi tiun neaŭtentikigitan formon por nefidindaj lokaj uzantoj aŭ por LAN-alvizaĝa auskultanto.

Paŝo 3: kontrolu la itineron el la ĝusta fonto

external elektas eliran fontadreson; ĝi ne instalas WireGuard-itinieron. Legnurka serĉo por la ekzempla fonto kaj celo:

ip -4 route get 10.60.0.20 from 10.77.0.2

Rulu tion en la reala reta nomspaco de Dante, ne en iu ajn ŝelo, kiun vi hazarde havas malfermita. La itinero, la elekto de WireGuard-partnero, la permeso ĉe la fora flanko kaj la revena vojo ĉiuj devas kongrui kun tiu fontadreso. Sukcesa serĉo estas necesa kaj ne sufiĉa, ĉar ĝi diras nenion pri tio, ĉu la malproksima fino akceptas la peton.

Rezistu la tenton aldoni defaŭltan itineron por ke la serĉo sukcesu. La proksa pordo ekzistas nur sur ĉi tiu laborejo; ŝanĝi la defaŭltan itineron de la gastiganto por krei ĝin inversigas la tutan dezajnon.

Paŝo 4: testu kun la intencita identeco

Post kiam la posedanto validigas la instalitan agordon kaj startas la instancon per sia servoadministrilo, ilustra peto estas:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

Kun socks5h, Dante plenumas la celan solvon, sed Dante kuras sur ĉi tiu laborejo, do la agordo mem ne sendas DNS al la malproksima fino de la tunelo. La aprobita solvilo, kiun Dante uzas, devas redoni la permesitan adreson por tiu nomo. La malplena listo sen prokso malhelpas hereditan escepton silente preterpasi SOCKS.

Konservu la validigon de HTTPS-gastigantnomo kaj atestilo en la testo, poste inspektu la realan auskultanton kaj konfirmu ambaŭ duonojn de la kontrakto: la permesita peto sukcesas kaj ekskludita celo malsukcesas. Ankaŭ kontrolu, ke neapogataj plusendaj komandoj restas malpermesitaj, ĉar ĉi tiu fragmento permesas la komandon SOCKS CONNECT super TCP kaj nenion similan al ĝenerala UDP aŭ tut-aparata tunelo.

Paŝo 5: decidu, kio okazas kiam la tunelo falas

Testu tunelan perdon kaj restarigon de la instanco antaŭ ol nomi ĉi tion produkta. Kontrolisto, kiu startas Dante post WireGuard, ne kreas fail-closed itineradon, kaj ĝi ankaŭ ne kreas fail-closed DNS; ambaŭ devas esti devigataj tra la reta posedanto. Observu, kion la aplikaĵo faras kiam la tunelo estas malsupre: pura eraro estas bona rezulto, silenta falback al publika solvilo ne estas.

Kunordigu ĝisdatigojn, se la ligita tunela adreso ŝanĝiĝas, ĉar external estas fiksita al ĝi. Kiam la aranĝo ne plu necesas, retiru ĉi tiun instancon kaj la proksagordon de la aplikaĵo kune, kaj lasu la WireGuard-itinieron al tiu, kiu posedas ĝin.

Rilataj artikoloj