Dante SOCKS loopback-ում միայն WireGuard-ով աշխատող HTTPS ծառայության համար

Այս ուղեցույցը պրոքսիին ծանոթ հավելվածին տալիս է մուտք դեպի գոյություն ունեցող WireGuard ուղի՝ առանց VPN սերվերի կամ ինտերնետում պրոքսի պորտ հրապարակելու։ SOCKS դեմոնը տրամադրում է հավելվածի միջերեսը, WireGuard-ը տրամադրում է արդեն հաստատված IP ուղին, և նրանցից ոչ մեկը ձեր փոխարեն չի նույնականացնում օգտվողին։ Ներքևի յուրաքանչյուր քայլ ստեղծում է մի բան, որը կարող եք ստուգել, և յուրաքանչյուրն ունի հետադարձ՝ կանգնեցրեք օրինակը, հեռացրեք կանոնը կամ հեռացրեք հավելվածի պրոքսի կարգավորումը։ Այստեղ ոչինչ չի փոխում հոսթի լռելյայն երթուղին։

Օրինակը ենթադրում է, որ Dante 1.4.x-ը տեղադրված է որպես հատուկ, կառավարվող օրինակ վստահելի Linux աշխատանքային կայանում, և փաթեթի տրամադրած ծառայության հաշիվն ու գրանցման կարգավորումը թողնված են իրենց տեղում։ Աշխատանքային կայանը տիրապետում է 10.77.0.2-ին իր WireGuard միջերեսում, հասնում է 10.60.0.20:443-ին այդ թունելով, և ծառայության սեփական անունը app.corp.example է։

Քայլ 1. լսողը կապեք միայն loopback-ին

Տեղադրեք ցանցի, մեթոդի և կանոնների բաժինները օրինակի ակտիվ կարգավորման մեջ՝ փոխարինելով օրինակի հասցեները։ Սերվերի բոլոր կարգավորումները գալիս են կանոնների բլոկներից առաջ.

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
}

Սա բեկոր է, ոչ թե փաթեթի օգտվողի և գրանցման կարգավորումների փոխարինում։ Ընտրեք չօգտագործված տեղական պորտ և հաստատեք, որ այս հատուկ օրինակը չունի այլ լսողներ, ավելի լայն անցման կանոններ և պայմանագիրը կփոխող վերին շղթայի մուտքեր։ Եթե նախորդ կարգավորումը թողել է socks pass առանց նպատակակետի սահմանափակման, հեռացրեք այն նախքան որևէ բան փորձարկելը։

Այս քայլի հետադարձը օրինակի կանգնեցումն է. կարգավորման ֆայլը կարող է մնալ սկավառակի վրա, քանի դեռ վերադարձնում եք այն։

Քայլ 2. գրեք երկու կանոն, ոչ թե մեկ

Dante-ի կարգավորման տեղեկատուն երկու կանոնների տեսակներին տալիս է տարբեր խնդիրներ։ Հաճախորդի կանոնը թույլ է տալիս կապ loopback լսողին, և դրա նպատակակետը հենց լսողի հասցեն է։ SOCKS կանոնը թույլ է տալիս պահանջված հետագա կապը հաստատված հոսթին և պորտին։ Չհամապատասխանող հարցումները արգելափակվում են լռելյայն, և դրա համար բացակայող կանոնը նույն տեսքն ունի, ինչ կոտրված երթուղին։

Ուշադրություն դարձրեք, ինչ այս կարգավորումը դիտավորյալ չի անում. այն SOCKS գաղտնաբառ չի պահանջում։ Դա հարմար է վստահելի տեղական հոսթի համար, և դա օգտվողի նույնականացում չէ։ Այդ մեքենայի ցանկացած այլ գործընթաց նույնպես կարող է օգտագործել loopback-ը։ Պահպանեք հեռավոր հավելվածի սեփական նույնականացումը և չօգտագործեք այս չնույնականացված ձևը անվստահելի տեղական օգտվողների կամ LAN-ին նայող լսողի համար։

Քայլ 3. ստուգեք երթուղին ճիշտ աղբյուրից

external ընտրում է ելքային աղբյուրի հասցե. այն WireGuard երթուղի չի տեղադրում։ Միայն կարդալու որոնում օրինակի աղբյուրի և նպատակակետի համար.

ip -4 route get 10.60.0.20 from 10.77.0.2

Գործարկեք դա Dante-ի իրական ցանցային անվանատարածքում, ոչ թե ձեր բացած ցանկացած shell-ում։ Երթուղին, WireGuard գործընկերոջ ընտրությունը, հեռավոր կողմի թույլտվությունը և վերադարձի ուղին բոլորը պետք է համապատասխանեն այդ աղբյուրի հասցեին։ Հաջող որոնումը անհրաժեշտ է և ոչ բավարար, որովհետև այն ոչինչ չի ասում, թե արդյոք հեռավոր ծայրը ընդունում է հարցումը։

Դիմացեք գայթակղությանը ավելացնել լռելյայն երթուղի, որպեսզի որոնումը հաջողվի։ Պրոքսի պորտը գոյություն ունի միայն այս աշխատանքային կայանում. հոսթի լռելյայն երթուղին փոխելը այն ստեղծելու համար շրջում է ամբողջ ձևավորումը։

Քայլ 4. փորձարկեք նախատեսված ինքնությամբ

Այն բանից հետո, երբ սեփականատերը վավերացնի տեղադրված կարգավորումը և գործարկի օրինակը իր ծառայությունների կառավարիչով, օրինակելի հարցումը սա է.

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

Ի socks5h-ով Dante-ն կատարում է նպատակակետի լուծումը, բայց Dante-ն աշխատում է այս աշխատանքային կայանում, ուստի կարգավորումը ինքնուրույն DNS չի ուղարկում թունելի հեռավոր ծայրին։ Dante-ի օգտագործած հաստատված լուծիչը պետք է վերադարձնի թույլատրված հասցեն այդ անվան համար։ Դատարկ no-proxy ցանկը թույլ չի տալիս ժառանգված բացառությանը լուռ շրջանցել SOCKS-ը։

Պահպանեք HTTPS հոսթի անվան և վկայագրի ստուգումը փորձարկման մեջ, ապա ստուգեք իրական լսողը և հաստատեք պայմանագրի երկու կեսերը. թույլատրված հարցումը հաջողվում է, իսկ բացառված նպատակակետը ձախողվում է։ Ստուգեք նաև, որ չաջակցվող փոխանցման հրամանները մնում են մերժված, որովհետև այս բեկորը թույլ է տալիս SOCKS CONNECT հրամանը TCP-ի վրա և ոչինչ ընդհանուր UDP կամ ամբողջ սարքի թունելի նման։

Քայլ 5. որոշեք, թե ինչ է լինում, երբ թունելը ընկնում է

Փորձարկեք թունելի կորուստը և օրինակի վերագործարկումը նախքան սա արտադրություն անվանելը։ Վերահսկիչը, որը Dante-ն գործարկում է WireGuard-ից հետո, fail-closed երթուղավորում չի ստեղծում և fail-closed DNS էլ չի ստեղծում. երկուսն էլ պետք է պարտադրվեն ցանցի սեփականատիրոջ միջոցով։ Դիտեք, թե ինչ է անում հավելվածը, երբ թունելը կանգնած է. մաքուր սխալը լավ արդյունք է, հանրային լուծիչին լուռ անկումը՝ ոչ։

Համաձայնեցրեք թարմացումները, եթե կապված թունելի հասցեն փոխվի, որովհետև external ամրացված է դրան։ Երբ այս դասավորությունն այլևս պետք չէ, միասին դուրս բերեք այս օրինակը և հավելվածի պրոքսի կարգավորումը, և WireGuard ուղին թողեք նրան, ով տիրապետում է այն։