Šī rokasgrāmata sniedz proxy pārzinošai lietotnei piekļuvi esošajam WireGuard ceļam, nepublicējot proxy portu VPN serverī vai internetā. SOCKS dēmons nodrošina lietotnes saskarni, WireGuard nodrošina jau apstiprināto IP ceļu, un neviens no tiem neveic lietotāja autentifikāciju jūsu vietā. Katrs solis zemāk rada kaut ko pārbaudāmu, un katram ir atsaukšana: apturiet instanci, noņemiet noteikumu vai noņemiet lietotnes proxy iestatījumu. Nekas šeit nemaina resursdatora noklusējuma maršrutu.

Piemērs pieņem, ka Dante 1.4.x ir instalēts kā atsevišķa, pārvaldīta instance uz uzticamas Linux darbstacijas, un pakotnes nodrošinātais servisa konts un reģistrēšanas konfigurācija ir atstāti savās vietās. Darbstacija pārvalda 10.77.0.2 savā WireGuard saskarnē, sasniedz 10.60.0.20:443 caur šo tuneli, un pakalpojuma īstais nosaukums ir app.corp.example.

1. solis: piesaistiet klausītāju tikai loopback

Ievietojiet tīkla, metodes un noteikumu sadaļas instances aktīvajā konfigurācijā, aizstājot piemēra adreses. Visi servera iestatījumi ir pirms noteikumu blokiem:

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
}

Šis ir fragments, nevis pakotnes lietotāja un reģistrēšanas iestatījumu aizstājējs. Izvēlieties neizmantotu lokālo portu un apstipriniet, ka šai atsevišķajai instancei nav citu klausītāju, plašāku caurlaides noteikumu un augšupējas ķēdes ierakstu, kas mainītu līgumu. Ja iepriekšējā konfigurācija atstāja socks pass bez galamērķa ierobežojuma, noņemiet to pirms kaut kā testēšanas.

Šī soļa atsaukšana ir instances apturēšana; konfigurācijas fails var palikt diskā, kamēr to atjaunojat.

2. solis: rakstiet divus noteikumus, nevis vienu

Dante konfigurācijas uzziņa abiem noteikumu veidiem piešķir dažādus uzdevumus. Klienta noteikums pieļauj savienojumu ar loopback klausītāju, un tā galamērķis ir paša klausītāja adrese. SOCKS noteikums atļauj pieprasīto turpmāko savienojumu ar apstiprināto resursdatoru un portu. Neatbilstoši pieprasījumi tiek bloķēti pēc noklusējuma, tāpēc trūkstošs noteikums izskatās tieši tāpat kā salauzts maršruts.

Ievērojiet, ko šī konfigurācija apzināti nedara: tā nepieprasa SOCKS paroli. Tas atbilst uzticamam lokālam resursdatoram, un tā nav lietotāja autentifikācija. Jebkurš cits process šajā mašīnā arī var izmantot loopback. Saglabājiet attālinātās lietotnes pašas autentifikāciju un neizmantojiet šo neautentificēto formu vēlreiz neuzticamiem lokāliem lietotājiem vai LAN vērstam klausītājam.

3. solis: pārbaudiet maršrutu no pareizā avota

external izvēlas izejošo avota adresi; tas neinstalē WireGuard maršrutu. Tikai lasīšanas vaicājums piemēra avotam un galamērķim:

ip -4 route get 10.60.0.20 from 10.77.0.2

Palaidiet to Dante īstajā tīkla nosaukumtelpā, nevis kādā nejauši atvērtā čaulā. Maršrutam, WireGuard partnera izvēlei, attālinātās puses atļaujai un atgriešanās ceļam visiem jāatbilst šai avota adresei. Veiksmīgs vaicājums ir nepieciešams un nepietiekams, jo tas neko nepasaka par to, vai tālā gala puse pieņem pieprasījumu.

Pretojieties kārdinājumam pievienot noklusējuma maršrutu, lai vaicājums izdotos. Proxy ports pastāv tikai šajā darbstacijā; resursdatora noklusējuma maršruta maiņa, lai to izveidotu, apgriež visu dizainu otrādi.

4. solis: testējiet ar paredzēto identitāti

Pēc tam, kad īpašnieks validē instalēto konfigurāciju un palaiž instanci caur savu pakalpojumu pārvaldnieku, ilustratīvs pieprasījums ir:

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

Ar socks5h, Dante veic galamērķa izšķiršanu, bet Dante darbojas šajā darbstacijā, tāpēc iestatījums pats neaizsūta DNS uz tuneļa tālo galu. Apstiprinātajam risinātājam, ko Dante izmanto, jāatgriež atļautā adrese šim nosaukumam. Tukšais bez-proxy saraksts neļauj mantotam izņēmumam klusi apiet SOCKS.

Saglabājiet testā HTTPS resursdatora nosaukuma un sertifikāta validāciju, pēc tam apskatiet faktisko klausītāju un apstipriniet abas līguma puses: atļautais pieprasījums izdodas, bet izslēgtais galamērķis neizdodas. Pārbaudiet arī, ka neatbalstītās pārsūtīšanas komandas paliek noraidītas, jo šis fragments atļauj SOCKS CONNECT komandu TCP virsū un neko līdzīgu vispārīgam UDP vai visas ierīces tunelim.

5. solis: izlemiet, kas notiek, kad tunelis nokrīt

Pārbaudiet tuneļa zudumu un instances restartu pirms saukt to par ražošanu. Uzraugs, kas palaiž Dante pēc WireGuard, neveido fail-closed maršrutēšanu un neveido arī fail-closed DNS; abi jāīsteno caur tīkla īpašnieku. Vērojiet, ko lietotne dara, kad tunelis ir izslēgts: tīra kļūda ir labs rezultāts, klusa pāriešana uz publisku risinātāju nav.

Koordinējiet atjauninājumus, ja piesaistītā tuneļa adrese mainās, jo external ir tai piesaistīts. Kad šī kārtība vairs nav vajadzīga, izbeidziet šo instanci un lietotnes proxy iestatījumu kopā, un atstājiet WireGuard ceļu tam, kuram tas pieder.

Saistītie raksti