Dante SOCKS në loopback për një shërbim HTTPS vetëm përmes WireGuard

Ky udhëzues i jep një aplikacioni që e njeh proxyn akses në një rrugë ekzistuese WireGuard pa publikuar një port proxy në serverin VPN ose në internet. Daemoni SOCKS ofron ndërfaqen e aplikacionit, WireGuard ofron rrugën IP të miratuar tashmë, dhe asnjëri prej tyre nuk e vërteton përdoruesin në vendin tuaj. Çdo hap më poshtë prodhon diçka që mund ta inspektoni, dhe secili ka një kthim: ndalni instancën, hiqni rregullin ose hiqni cilësimin e proxy-t të aplikacionit. Asgjë këtu nuk e ndryshon rrugën e paracaktuar të hostit.

Shembulli supozon se Dante 1.4.x është instaluar si një instancë e dedikuar dhe e menaxhuar në një stacion pune Linux të besuar, me llogarinë e shërbimit dhe konfigurimin e regjistrimit të ofruara nga paketa të lëna në vendin e tyre. Stacioni i punës zotëron 10.77.0.2 në ndërfaqen e tij WireGuard, arrin 10.60.0.20:443 përmes atij tuneli, dhe emri i duhur i shërbimit është app.corp.example.

Hapi 1: lidhni dëgjuesin vetëm me loopback

Vendosni seksionet e rrjetit, metodës dhe rregullave në konfigurimin aktiv të instancës, duke zëvendësuar adresat e shembullit. Të gjitha cilësimet e serverit vijnë përpara blloqeve të rregullave:

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
}

Ky është një fragment, jo një zëvendësim për cilësimet e përdoruesit dhe të regjistrimit të paketës. Zgjidhni një port lokal të papërdorur dhe konfirmoni se kjo instancë e dedikuar nuk ka dëgjues të tjerë, rregulla kalimi më të gjera dhe shënime zinxhiri sipër që do të ndryshonin kontratën. Nëse një konfigurim i mëparshëm ka lënë një socks pass pa kufizim destinacioni, hiqeni para se të testoni çdo gjë.

Kthimi për këtë hap është ndalimi i instancës; skedari i konfigurimit mund të mbetet në disk ndërsa e ktheni.

Hapi 2: shkruani dy rregulla, jo një

Referenca e konfigurimit të Dante u jep dy llojeve të rregullave detyra të ndryshme. Rregulli i klientit lejon një lidhje me dëgjuesin e loopback, dhe destinacioni i tij është adresa e vetë dëgjuesit. Rregulli SOCKS lejon lidhjen e mëtejshme të kërkuar drejt hostit dhe portit të miratuar. Kërkesat që nuk përputhen bllokohen si parazgjedhje, dhe për këtë arsye një rregull që mungon duket identik me një rrugë të prishur.

Vini re çfarë nuk bën qëllimisht ky konfigurim: nuk kërkon asnjë fjalëkalim SOCKS. Kjo i përshtatet një hosti lokal të besuar, dhe nuk është vërtetim përdoruesi. Çdo proces tjetër në atë makinë mund të përdorë gjithashtu loopback. Mbani vërtetimin e vetë aplikacionit të largët dhe mos e ripërdorni këtë formë të pavërtetuar për përdorues lokalë jo të besuar ose për një dëgjues të kthyer nga LAN-i.

Hapi 3: verifikoni rrugën nga burimi i duhur

external zgjedh një adresë burimi dalëse; nuk instalon një rrugë WireGuard. Kërkim vetëm-lexim për burimin dhe destinacionin e shembullit:

ip -4 route get 10.60.0.20 from 10.77.0.2

Ekzekutoni këtë në hapësirën e vërtetë të emrave të rrjetit të Dante, jo në ndonjë shell që e keni hapur. Rruga, zgjedhja e partnerit WireGuard, leja në anën e largët dhe rruga e kthimit duhet të përputhen të gjitha me atë adresë burimi. Një kërkim i suksesshëm është i nevojshëm dhe jo i mjaftueshëm, sepse nuk thotë asgjë nëse skaji i largët e pranon kërkesën.

Rezistoni tundimit për të shtuar një rrugë të paracaktuar që kërkimi të ketë sukses. Porti proxy ekziston vetëm në këtë stacion pune; ndryshimi i rrugës së paracaktuar të hostit për ta krijuar e përmbys të gjithë modelin.

Hapi 4: provoni me identitetin e synuar

Pasi pronari të validon konfigurimin e instaluar dhe ta nisë instancën përmes menaxherit të shërbimeve, një kërkesë ilustruese është:

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

Me socks5h, Dante kryen zgjidhjen e destinacionit, por Dante xitet në këtë stacion pune, prandaj cilësimi nuk e dërgon vetë DNS-në në skajin e largët të tunelit. Zgjidhësi i miratuar që përdor Dante duhet të kthejë adresën e lejuar për atë emër. Lista bosh pa proxy pengon një përjashtim të trashëguar të anashkalojë në heshtje SOCKS.

Ruani validimin e emrit të hostit dhe certifikatës HTTPS në test, pastaj inspektoni dëgjuesin aktual dhe konfirmoni të dyja gjysmat e kontratës: kërkesa e lejuar ka sukses dhe një destinacion i përjashtuar dështon. Verifikoni gjithashtu se komandat e përcjelljes të pambështetura mbeten të refuzuara, sepse ky fragment lejon komandën SOCKS CONNECT mbi TCP dhe asgjë që i ngjan një tuneli të përgjithshëm UDP ose të të gjithë pajisjes.

Hapi 5: vendosni çfarë ndodh kur tuneli bie

Provoni humbjen e tunelit dhe rinisjen e instancës përpara se ta quani prodhim. Një mbikëqyrës që nis Dante pas WireGuard nuk krijon rrugëtim fail-closed, dhe nuk krijon as DNS fail-closed; të dyja duhet të imponohen përmes pronarit të rrjetit. Vëzhgoni çfarë bën aplikacioni kur tuneli është jashtë: një gabim i pastër është rezultat i mirë, një rënie e heshtur te një zgjidhës publik nuk është.

Koordinoni përditësimet nëse adresa e lidhur e tunelit ndryshon, sepse external është e fiksuar në të. Kur rregullimi nuk është më i nevojshëm, tërhiqni këtë instancë dhe cilësimin e proxy-t të aplikacionit së bashku, dhe lini rrugën WireGuard atij që e zotëron.