Թույլ տալ մեկ OpenVPN հաճախորդի SSH-ով հասնել մյուսին՝ չբացելով լողավազանը

Մեկ հաճախորդ պետք է հասնի մեկ այլ հաճախորդի SSH ծառայությանը, իսկ լողավազանի մնացած մասը պետք է մնա նույնքան մեկուսացված, որքան այսօր։ Գայթակղիչ անջատիչը client-to-client-ն է, որը միանգամից միացնում է հավասարակիցների միջև մուտքը բոլորի համար և որոշումը հանձնում է OpenVPN-ին՝ միջուկի փոխարեն։ Ավելի նեղ պատասխանը թողնում է այդ անջատիչը անջատված և թույլ է տալիս սերվերի սեփական երթուղմանը և հրապատին կրել ճիշտ մեկ հոսք։

Մեխանիզմն ավելի կարևոր է, քան կանոնի տեքստը, որովհետև երկու մոտեցումները փաթեթը դնում են տարբեր տեղերում։ Իմանալը, թե որն եք ընտրել, բացատրում է և՛ այն կանոնը, որը կարծես ոչինչ չի անում, և՛ այն հավասարակիցը, որը միանում է առանց դրա։

Ուր է client-to-client-ը տեղափոխում փաթեթը

Երբ client-to-client-ը միացված է, սերվերը փոխանցում է հավասարակցի փաթեթը ներքուստ՝ թունելի սարքից կրկին դուրս ուղարկելու փոխարեն, այնպես որ փաթեթը երբեք չի հասնում միջուկի փոխանցման ուղուն։ Դա հարմար է և նաև նշանակում է, որ ձեր հրապատը երբեք չի տեսնում այն հոսքը, որը պետք է հսկեր։ Թողեք տարբերակը անջատված, և սերվերը երթուղավորում է փաթեթը կրկին դուրս նույն ինտերֆեյսով, ինչը այն դնում է netfilter-ի առջև։ Նույն ինտերֆեյսը ներս, նույնը՝ դուրս, և FORWARD շղթան ձայն ունի։

Փոխանակումը հստակ է՝ դուք շահում եք մեկ քաղաքականության կետ և վերցնում եք երթուղավորումն ու փոխանցումը, որ կարճուղին անում էր ձեզ համար։ Այդ աշխատանքը փոքր է մեկ հոսքի համար և աճում է յուրաքանչյուր ավելացված բացառության հետ։ Հաշվեք բացառությունները հիմա, որովհետև կանոնների հավաքածուն է այն տեղը, որտեղ իրականում ապրում է հավասարակիցների միջև քաղաքականությունը։

Ուղին, որ իրականում անցնում է հավասարակցի փաթեթը

Ենթադրենք Linux Community OpenVPN 2.6 ծառայություն, օգտագործողի տարածքում TUN մշակում՝ DCO-ի փոխարեն, ենթացանցային տոպոլոգիա, tun0 և 10.44.0.0/24 լողավազան՝ A հաճախորդը 10.44.0.21-ում և B հաճախորդը 10.44.0.37-ում։ Ենթացանցային տոպոլոգիայի դեպքում A-ի ստացած հասցեն և ցանցային դիմակն արդեն ծածկում են լողավազանը, ուստի A-ն փաթեթն ուղարկում է թունելի սարքին՝ առանց լրացուցիչ մղված երթուղու։ Ստուգեք A-ի փաստացի երթուղին՝ ենթադրելու փոխարեն։

Սերվերում փաթեթը հասնում է B-ին հասցեագրված, ինչը տեղական հասցե չէ, ուստի այն փոխանցվում է։ IPv4 փոխանցումը պետք է միացված լինի, որպեսզի դա ընդհանրապես տեղի ունենա, և երթուղու որոնումը պետք է փաթեթը կրկին դուրս ուղարկի tun0-ով։ Հրապատը հետևաբար տեսնում է փոխանցված հոսք՝ նույն ինտերֆեյսով երկու կողմերում, և դա այն մանրամասնությունն է, որը բաց թողնում են կանոնների մեծ մասը։ Այստեղ աղբյուրի թարգմանություն պետք չէ, և հենց A-ի հասցեն անձեռնմխելի պահելն է, որ թույլ է տալիս B-ին կիրառել իր սեփական՝ աղբյուրի վրա հիմնված կանոնը։

Երկու կանոն սերվերում, այս հերթականությամբ

Երեք կանոն են կրում ամբողջ թույլտվությունը՝ փոխանցումը, զույգի բացառությունը և թունելի զույգի համար լռելյայն գցումը։ Ընդունման կանոնը նշում է զույգը և ծառայությունը, ուստի թույլտվությունը դիմանում է աճող լողավազանին։ Տեղադրեք այն ցանկացած ընդհանուր մերժումից առաջ թունել-թունել երթևեկության համար, որովհետև հաղթում է առաջին համընկնումը:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Այդ հրամանները պատկերավոր են և պատկանում են այն մեխանիզմին, որով ձեր հոսթն ապահովում է կանոնների պահպանումը. գործարկման պահին արված ներդիրը անհետանում է հաջորդ բեռնարկումից։ Հենց վիճակային կանոնն է, որ թույլ է տալիս B-ի պատասխաններին և TCP ձեռքսեղմմանը վերադառնալ առանց երկրորդ՝ հայելային ընդունման:

Ստուգեք հաշվիչները հետո, ոչ թե կանոնների ցանկը, որովհետև երբեք չհամընկնող կանոնը նույն տեսքն ունի, ինչ աշխատողը։ Եթե հաշվիչները մնում են զրոյի, փաթեթը չի գնում այն ուղով, որը դուք կարծում եք։

Ինչ դեռ պետք է թույլատրի B-ն

B-ն է վարում SSH ծառայությունը, ուստի B-ն է որոշում՝ արդյոք ինչ-որ բան լսում է թունելի հասցեում, և արդյոք իր սեփական հոսթի հրապատը ընդունում է աղբյուրը։ Սերվերում տրված ցանցային թույլտվությունը թույլտվություն չէ B-ի ոչ մի հաշվի համար, և հոսթի բանալու ստուգումն ու օգտագործողի նույնականացումը դեռ գործում են, ինչպես ցանկացած այլ տեղից։

Նախ փորձարկեք դրական դեպքը՝ A-ից B-ի թունելի հասցեին նոր SSH կապ, ընդունված սպասվող հոսթի բանալիով։ Ապա փորձարկեք այլ հավասարակցի կամ այլ պորտ և հաստատեք, որ այն մերժվում է, որովհետև լուռ ամեն ինչ թույլատրող թույլտվությունը չի տարբերվում աշխատողից, քանի դեռ դա կարևոր չի դարձել։ Այդ փորձարկման երկու կեսերն էլ անհրաժեշտ են, և երկրորդն է այն, ինչը մարդիկ բաց են թողնում։

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