Մեկ NIC թե՞ երկու. VPN սերվերի ինտերֆեյսների դասավորության որոշումը

Շատ VPN սերվերների համար բավական է մեկ ֆիզիկական ադապտեր, և դա նույնպես համընդհանուր լուծում չէ։ Գաղտնագրված կապը գալիս է այդ ադապտերով, VPN գործընթացն ապակոդավորում է այն, և դրանից հետո ներքին երթևեկությունը դուրս է գալիս վիրտուալ ինտերֆեյսով՝ նախքան տեղային ծառայության կամ երթուղավորված LAN-ի հասնելը։ Արդյո՞ք դա աշխատում է, կախված է երեք պայմանից՝ որտեղ է գտնվում նպատակակետը, ունի՞ LAN-ը վերադարձի ուղի դեպի հաճախորդների լողավազան, և արդյո՞ք մեկ ընդհանուր ֆիզիկական կապը տալիս է ձեզ այն մեկուսացումը, որը դուք պնդում եք։ Պատասխանեք այդ երեքին, և ադապտերների քանակը կհետևի դրանից։

Երեք պայմանները, որոնք որոշում են դա

Առաջին պայմանը նպատակակետն է։ VPN հոսթի վրա գտնվող ծառայությանը հասնում են միայն թունելի ինտերֆեյսով, մինչդեռ LAN-ում գտնվող հոսթը պահանջում է փոխանցում և վերադարձի ուղի։ Երկրորդ պայմանը հենց այդ վերադարձի ուղին է, որովհետև LAN սարքը պետք է իմանա, թե ինչպես հասնել հաճախորդների լողավազանին՝ կա՛մ երթուղով, կա՛մ սերվերի վրա հասցեի թարգմանությամբ։

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

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

Երկու ադապտեր մնում է օրինական ընտրություն, երբ ֆիզիկական գոտիները, առանձին uplink-ները, թողունակությունը կամ ժապավենից դուրս վերականգնման ուղին հիմնավորում են դրանք։ Դրանք կոնկրետ պահանջներ են, և արժե դրանք արձանագրել նախքան որևէ մեկը ապարատ պատվիրելը։

Երբ ծառայությունը աշխատում է VPN հոսթի վրա

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

Երկու բան այնուամենայնիվ պետք է ճիշտ լինի՝ ծառայությունը պետք է լսի այնպիսի հասցեով, որին թունելը կարող է հասնել, և հոսթի ֆայրվոլը պետք է ընդունի թունելի ինտերֆեյսով եկող երթևեկությունը։ Երկուսն էլ երևում են ստորև բերված հրամաններում։

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Ծառայությունը միայն հանրային հասցեին կապելը կամ թունելի ինտերֆեյսը սխալմամբ զտելը ստեղծում է կապ, որը հասնում է հոսթին և հետո մահանում։ Դա VPN-ի խափանման տեսք ունի և սովորաբար սոքեթի կամ ֆայրվոլի որոշում է։

Երբ նպատակակետը LAN-ում է

Այստեղ է, որ մեկ ադապտերով նախագիծը ձեռք է բերում բարդ լինելու համբավը։ Սերվերը պետք է հաճախորդի փաթեթները փոխանցի դեպի LAN, իսկ LAN սարքը պետք է պատասխանները հետ ուղարկի հաճախորդների լողավազան։ Կամ այդ լողավազանը տանում եք որպես երթուղի LAN-ում, կամ սերվերի վրա թարգմանում եք աղբյուրի հասցեն, որպեսզի պատասխանները վերադառնան հենց սերվերին։

Երկու պատասխաններն էլ օրինական են, և նրանք տարբեր կերպ են ձախողվում։ Վերադարձի երթուղին սկզբնական հաճախորդի հասցեն տեսանելի է թողնում նպատակակետի համար, ինչը լավ է մատյանների և վատ է այն ֆայրվոլի կանոնների համար, որոնք ենթադրում են LAN հասցեներ։ Թարգմանությունը LAN-ը պահում է պարզ և թաքցնում է հաճախորդի ինքնությունը նպատակակետից։

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

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

Ինչու alias-ը երկրորդ գոտի չի ստեղծում

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

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

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

Ստուգեք դասավորվածությունը ձեր թույլատրած երթևեկի դեմ

Թվարկեք երթևեկության դասերը, որոնք սերվերը պետք է կրի՝ հաճախորդից հոսթ, հաճախորդից LAN, հոսթից LAN և գաղտնագրված արտաքին կապը։ Յուրաքանչյուր դաս ունի աղբյուր, նպատակակետ և ինտերֆեյս, և դասավորվածությունը պետք է բավարարի բոլոր չորսին միաժամանակ։ Նախագիծը, որը կարգավորում է դրանցից երեքը, սովորաբար հենց այն է, որ տոմսեր է ծնում։

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

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Եթե արտաքին գրավումը ցույց է տալիս գաղտնագրված երթևեկությունը, իսկ ներքին գրավումը ցույց է տալիս ապակոդավորված երթևեկությունը թունելի ինտերֆեյսում, մինչ ֆիզիկական ադապտերը կրում է երկուսն էլ, ապա մեկ NIC-ն է կատարում աշխատանքը։ Եթե ներքին գրավումը դատարկ է, խնդիրը թունելում կամ փոխանցման կանոններում է, ոչ թե ադապտերների քանակի մեջ։ Որոշեք տոպոլոգիան այդ երկու գրավումներից և երթուղային աղյուսակից, և հաջորդ փոփոխությունը չափելու բան կունենա։