Կայք-կայք կամ հեռահար մուտք VPN-ով՝ ինչն ինչ է միացնում
Մեկը միացնում է դարպասները, մյուսը՝ սարքերը։ Համեմատեք տրաֆիկի ընտրիչները երթուղիների հետ, պլանավորեք հասցեավորումը, ապա ստուգեք փոխանցումն ու քաղաքականությունը իրական հոսթից։
Երկու լուծումներն էլ կոչվում են VPN և լուծում են տարբեր խնդիրներ։ Կայք-կայք թունելը միացնում է երկու դարպաս, այնպես որ դրանց հետևում գտնվող յուրաքանչյուր հոսթ կարող է հասնել մյուս կողմի թույլատրված հասցեներին՝ առանց որևէ բան տեղադրելու։ Հեռահար մուտքի թունելը առանձին սարքերը միացնում է ցանցին՝ մեկ հաճախորդ միաժամանակ։ Համեմատությունը կարևոր է, որովհետև տեղակայման սխալների մեծ մասն առաջանում է մեկը կարգավորելիս մյուսի վարքը սպասելուց, և ախտանիշը սովորաբար ժամանակի սպառումն է այն ծառայությունում, որին թունելն իսկապես հասել է։
Երկու լուծում, երկու սահման
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
Լուծումներից ոչ մեկը չի ընդլայնում LAN հեռարձակման տիրույթը։ Հեռավոր կողմի սարքերը չեն հայտնվում տեղական հայտնաբերման ցանկում, և դա ակնկալելը առաջին ենթադրությունն է, որից պետք է հրաժարվել։ Ձեր կողմից դիտավորյալ հրապարակված մասնավոր DNS անունները ավելի կանխատեսելի են, քան ցանկացած հայտնաբերման արձանագրություն, և դիմանում են մատակարարի փոփոխությանը։
Վերցրեք 10.10.0.0/24-ը մի կայքում և 10.20.0.0/24-ը մյուսում։ A դարպասին անհրաժեշտ է երթուղի կամ տրաֆիկի ընտրիչ, որը 10.20.0.0/24 նախածանցը ուղարկում է թունել, իսկ B դարպասին՝ դրա հայելային պատկերը։ Այնուհետև երկու կողմերի հոսթերն օգտագործում են սովորական IP կապ և երբեք չեն իմանում, որ թունել գոյություն ունի։ Այդ անտեսանելիությունը հատկանիշն է, և դրա համար էլ խափանումները նման են սովորական ցանցային սխալների, ոչ թե թունելի սխալների։
Քաղաքականության վրա հիմնված և երթուղու վրա հիմնված նույն թունելը չեն
Քաղաքականության վրա հիմնված IPsec տեղակայման ժամանակ բանակցված տրաֆիկի ընտրիչները հստակորեն որոշում են, թե աղբյուր-նպատակակետ որ զույգերն են պաշտպանված։ Եթե մի դարպասի հետևում հայտնվում է նոր ենթացանց, և ոչ մի ընտրիչ չի ծածկում այն, թունելը մնում է աշխատունակ, և նոր ենթացանցը պարզապես չի տեղափոխվում։ Երթուղու վրա հիմնված լուծման դեպքում ինտերֆեյսն ընդունում է տրաֆիկը, և որոշումը կայացնում է երթուղային աղյուսակը, ինչը նախածանց ավելացնելը դարձնում է երթուղու փոփոխություն, այլ ոչ թունելի վերաբանակցում։
StrongSwan-ը ուղղակիորեն ցուցադրում է երկու տեսքերը, և դրանք միասին կարդալն այն միջոցն է, որով պարզում եք, թե որ մոդելն եք իրականում տեղակայել։
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'Ընտրիչների ցանկը, որտեղ բացակայում է ձեզ անհրաժեշտ նախածանցը, բացատրում է խափանումը առանց որևէ փաթեթի որսման, իսկ սխալ ինտերֆեյսի ցույց տվող երթուղին բացատրում է հայելային խափանումը վերադարձի ճանապարհին։ Կարդացեք երկուսն էլ, նախքան ինչ-որ բան վերաբանակցելը, որովհետև բանալու նորացումը չի ավելացնի այն ընտրիչը, որը երբեք չեք կարգավորել։
Պլանավորեք հասցեավորումը թունելից առաջ
Հատվող տիրույթները նախագծման այն սխալն են, որը հնարավոր չէ ուղղել կարգավորումներով։ Եթե երկու կայքերն էլ օգտագործում են 192.168.1.0/24, ապա 192.168.1.50-ի կարիք ունեցող հոսթն ունի երկու թեկնածու և ընտրելու ոչ մի միջոց։ Թունելը կնույնականացվի, անվտանգության ասոցիացիաները կհաստատվեն, և երթուղային որոշումը միևնույն է սխալ կամ երկիմաստ կլինի։
Ընտրեք երեք ազնիվ տարբերակներից մեկը՝ վերահամարակալել մեկ կայքը, թարգմանել հատվող տիրույթը դարպասում, որպեսզի յուրաքանչյուր կողմ տեսնի առանձին նախածանց, կամ հրաժարվել այդ հոսթերի ուղիղ երթուղավորումից և ծառայությունը հրապարակել այլ կերպ։ Յուրաքանչյուրն ունի գին, և առաջինը սովորաբար ամենաէժանն է երկամյա հորիզոնում։ Որոշեք մինչև թունելի գոյությունը, որովհետև հետո փոփոխությունը կանդրադառնա հին հասցե ունեցող յուրաքանչյուր սարքի։
MTU-ի հարցը նույնպես լուծեք վաղ։ Թունելը նվազեցնում է օգտակար բեռը, և մասնատման վրա հիմնված լուծումը այլ կերպ է վարվում, քան դարպասներում MSS-ը ամրագրողը։
Փոխանցումը և քաղաքականությունը թունելից դուրս են
Դարպասը պետք է պատրաստ լինի փաթեթներ փոխանցել թունելի ինտերֆեյսի և LAN ինտերֆեյսի միջև, և երկու ուղղություններն էլ քաղաքականություն են պահանջում, որը թույլատրում է ծառայությունը։ Linux-ում դրանք երկու առանձին կարգավորում են, գումարած firewall-ի կանոնները, որոնք որոշում են՝ փոխանցվող հոսքը ընդհանրապես թույլատրվա՞ծ է։
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTԸնդունող հոսթը ավելացնում է երրորդ շերտ՝ նրա սեփական firewall-ը դեռ պետք է ընդունի հաճախորդին հեռավոր ենթացանցից։ Ֆայլային սերվերը, որը թույլատրում է միայն իր տեղական /24-ը, կմերժի 10.20.0.7-ից փոխանցված տրաֆիկը, անկախ նրանից, թե թունելը որքան առողջ է թվում, և այդ մերժումը հեշտ է կարդալ որպես երթուղային խափանում։
Ստուգեք հոսթից, ոչ թե դարպասից
Դարպասի կողմից ուղարկված ping-ը կարող է հետևել այլ աղբյուրի հասցեի և այլ քաղաքականության, քան փոխանցված օգտվողի տրաֆիկը։ Դա այն դարձնում է թույլ փորձարկում և երբեմն մոլորեցնող՝ այն հաջողվում է, երբ հավելվածը ձախողվում է, կամ ձախողվում է, երբ հավելվածն աշխատում է։
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullՕգտագործեք իրական հոսթ, իրական աղբյուրի հասցե և այն իրական արձանագրությունը, որն օգտագործում է հավելվածը։ Ապա առանձին կարդացեք վերադարձի ուղին, որովհետև վերադարձի երթուղի չունեցող աշխատող առաջ ուղղությունը ստեղծում է ժամանակի սպառում, որը նույնական է արգելափակված ծառայությանը։
Ընտրեք լուծումը՝ ըստ այն հարցի, որին պատասխանում եք՝ դուք ցանցեր եք միացնում, թե սարքեր եք ընդունում։ Մնացած ամեն ինչ, ներառյալ այն, թե որ մատակարարին եք կարգավորում, բխում է այդ պատասխանից։