Redsocks-ը լսում է loopback-ի վրա, բայց VPN երթևեկությունը երբեք չի հասնում

Թունելը բարձրանում է, հաճախորդը կարող է ping անել դարպասին, և պրոքսիի ուղով անցնող յուրաքանչյուր վեբ հարցում մահանում է։ redsocks գործընթացը աշխատում է, և նրա պորտը լսում է, ուստի ծառայությունը առողջ է թվում հենց դարպասից։ Ձախողվում է առաքման քայլը՝ թունելից վերահասցեավորված փաթեթը չի իջնում այն socket-ի վրա, որը դուք գործարկել եք։ Կապման հասցեն և վերահասցեավորման թիրախը պետք է համընկնեն, և սովորաբար ստուգվում է դրանցից միայն մեկը։

Թե որտեղ է իրականում իջնում վերահասցեավորված փաթեթը

Դարպասի վրա թափանցիկ պրոքսին օգտագործում է REDIRECT-ը nat աղյուսակում PREROUTING-ում՝ մուտքային կապի նպատակակետը տեղական պորտի վերագրելու համար։ Վերագրված նպատակակետը տեղական հասցե է, ինչպես այն տեսնում է այն ինտերֆեյսը, որով ժամանել է փաթեթը, և ոչ թե այլ տեղ գործարկված գործընթացի loopback հասցեն։ Միայն 127.0.0.1-ին կապված լսողը ընդունում է կապեր, որոնք արդեն տեղական էին հոսթի վրա, և դա հենց այն դեպքն է, որը շարունակում է աշխատել, մինչ թունելի երթևեկությունը ձախողվում է։ Հաճախորդի սեփական loopback-ը երրորդ հասցեն է և երբեք դարպասի կանոնի թիրախը չէ։

Ուստի նախքան վերին մակարդակի հավատարմագրերին դիպչելը, հաստատեք երկու փաստ՝ թե որ տեղական հասցեին է կանոնը վերագրում, և թե որ հասցեին է կապված պրոքսիի socket-ը։

Կարդացեք լսողը և վերահասցեավորման կանոնը միասին

Տպեք socket-ների աղյուսակը և nat կանոնները մեկ անցումով, որովհետև այն պորտին մատնանշող կանոնը, որը ոչ ոք չի տիրապետում, նույն տեսքն ունի, ինչ սխալ հասցեին մատնանշող կանոնը։ sudo ss -ltnp | grep redsocks-ը ցույց է տալիս կապման հասցեն և տիրապետող գործընթացը։ sudo iptables -t nat -S PREROUTING-ը ցույց է տալիս REDIRECT թիրախը, և sudo iptables -t nat -L PREROUTING -v -n-ը ցույց է տալիս, թե արդյոք ինչ-որ բան համապատասխանել է դրան։

REDSOCKS անունով օգտագործողի շղթային թռիչքը ոչինչ չի տալիս, եթե այդ շղթան գոյություն չունի և չի կրում նախատեսված բացառությունները և REDIRECT գործողությունը։ Կարդացեք այն շղթան, որին այն թռչում է, sudo iptables -t nat -S REDSOCKS-ով, փոխանակ ենթադրելու, որ անունը կատարում է աշխատանքը։

Ապա համեմատեք երկու արժեքները։ Եթե կանոնը վերահասցեավորում է դարպասի հասցեին 12345 պորտում, և լսողը հաղորդում է 127.0.0.1:12345, ապա անհամապատասխանությունը բացատրում է ձախողումը առանց որևէ լրացուցիչ ախտորոշման։

Կապեք նեղ, ապա սահմանափակեք, թե ինչը կարող է հասնել դրան

Վերին մակարդակի օրինակելի կոնֆիգուրացիան լսողին դնում է loopback-ի վրա հիմնավոր պատճառով՝ թափանցիկ պրոքսին ընդունում է կապեր ցանկացածի անունից, ով կարող է հասնել դրան։ Կապումը 0.0.0.0-ի փոխելը ուղղում է առաքումը և միաժամանակ բացում պորտը բոլոր ինտերֆեյսներում, ինչը անվտանգության փոփոխություն է, ոչ թե չեզոք վերանորոգում։ Նախընտրեք կապել այն կոնկրետ տեղական հասցեին, որը թիրախավորում է վերահասցեավորումը, և պորտը փակ պահեք անվստահելի ինտերֆեյսներում։ Եթե ավելի լայն կապումն անխուսափելի է, ավելացրեք հոսթի firewall կանոն, որը թույլատրում է միայն թունելի աղբյուրի տիրույթը և դարպասի սեփական տեղական երթևեկությունը։

Պորտը հանրային ինտերֆեյսում բացելը երբեք պարտադիր չէ վերահասցեավորված VPN երթևեկության համար, որովհետև կապը ավարտվում է տեղականորեն վերագրումից հետո։ Մի ենթարկեք պրոքսին ինտերնետին, որպեսզի տեղական վերահասցեավորումը աշխատի։

Ապացուցեք այն հաճախորդից նոր կապով

Ստուգեք իրական VPN հաճախորդից թարմ TCP կապով, ոչ թե դարպասի shell-ից։ Հաճախորդի վրա curl -sS -o /dev/null -w '%{http_code}\n' http://example.com-ը անցնում է վերահասցեավորված ուղով սկզբից մինչև վերջ։

Ապա հաստատեք, որ անվստահելի ցանցից լսողին ուղղված ուղիղ կապը դեռ մերժվում է, և որ պրոքսիի սեփական վերին կապը նորից չի որսացվում նույն կանոնով։ Ռեկուրսիվ որսը երևում է որպես պրոքսի, որը կապվում է ինքն իր հետ և երբեք չի ավարտում հարցումը։ Ավելացրեք պրոքսիի նպատակակետը բացառությունների բազմությանը, կամ նշեք նրա ելքային փաթեթները, որպեսզի շղթան բաց թողնի դրանք։

Վերջապես, հիշեք, ինչը այս ուղին չի ծածկում։ redsocks-ի սովորական TCP վերահասցեավորումը UDP-ն, QUIC-ը կամ DNS-ը SOCKS երթևեկության չի վերածում, և մասնավոր նպատակակետերը սովորաբար պահանջում են բացահայտ բացառություններ։ Հաջող տեղական թեստը ապացուցում է միայն այն loopback ուղին, որը երբեք խնդիրը չի եղել։