Մեկ սարքը երթուղիչի VPN-ով պահանջում է երեք կանոն, ոչ թե անջատիչ
Մեկ սարքը երթուղիչի VPN-ով քաղաքականությամբ երթուղավորում է, ոչ թե նշման վանդակ։ նշված աղյուսակ, սահմանափակ NAT կանոն, գումարած DNS, IPv6 և LAN ուղիները, որոնք ուղեցույցները բաց են թողնում։
Երթուղիչի VPN-ում յուրաքանչյուր սարքի համար անջատիչ չկա։ այն անջատիչը, որը փնտրում եք, դյուրանցում է, որը ձեր փոխարեն գրում է քաղաքականությամբ երթուղավորման կանոններ։ Այն պահին, երբ մեկ նոթբուքը, մեկ պորտերի միջակայքը, մեկ հասցեների ցանկը կամ մեկ LAN հատվածը պետք է օգտագործի թունելը, մինչ մնացած ամեն ինչ մնում է WAN-ում, դուք կառուցում եք քաղաքականության ուղի, այլ ոչ թե միացնում գործառույթ։ Աշխատանքն ունի երեք շարժվող մաս, և յուրաքանչյուրը ձախողվում է տարբեր կերպ։ առանց ուղու նշված աղյուսակը լռություն է հիշեցնում, սխալ շղթայում դրված նշումը թվում է, թե ոչինչ չի պատահել, իսկ բացակայող NAT կանոնը նման է թունելի, որը միանում է և ոչինչ չի տեղափոխում։ Եվս երկու մաս կորչում է, որովհետև դրանք երբեք չեն հայտնվում mangle կանոնում, և դրանք DNS-ն ու IPv6-ն են։
Առասպել։ թունելը կլիենտի կարգավորում է
Երթուղիչի կողմի VPN կլիենտը մեկ կոպիտ բան լավ է անում։ այն 0.0.0.0/0-ը դնում է հիմնական երթուղավորման աղյուսակում և ուղղում դեպի թունել։ WireGuard-ը դա ածանցում է AllowedIPs-ից, OpenVPN-ը՝ հրված redirect-gateway-ից, և երկուսն էլ փոխում են ուղին երթուղիչի հետևում գտնվող յուրաքանչյուր հոսթի համար։ AllowedIPs-ի նեղացումը կամ route-nopull-ի ավելացումը փոխում է այն, ինչ տեղադրում է կլիենտը։ Այն չի փոխում, թե ում վրա է տարածվում տեղադրումը, որովհետև կլիենտը երբեք սարքեր չի տեսնում։ Այն տեսնում է միայն փաթեթներ։
Ըստ աղբյուրի կամ նպատակակետի ընտրությունը երթուղավորման որոշում է, ուստի այն պատկանում է երթուղիչի քաղաքականության շերտին։ mangle կանոն և երկրորդ աղյուսակ RouterOS-ում, MARK և ip rule OpenWrt-ում կամ DD-WRT-ում, կամ ֆայրվոլի կանոն, որի դարպասը թունելն է, pfSense-ում։ Netgate-ի WireGuard կլիենտի բաղադրատոմսը այն է, ինչ պետք է կարդալ նախքան գուշակելը, քանի որ այդ հարթակում կանոնի դարպասը, ինտերֆեյսի նշանակումը և ելքային NAT գրառումը բոլորը պետք է համաձայնեն, որպեսզի մեկ կլիենտ օգտագործի թունելը։
Առասպելի երկրորդ կեսը երկրորդ երթուղիչն է։ Եվս մեկ տուփ գնելը կամ սարքը հյուր SSID տեղափոխելը հաճախ աշխատում է, և պատճառը սարքավորումը չէ։ դա սարքը դնում է իր ենթացանցում, ինչը ձեզ տալիս է այն աղբյուրի ընտրիչը, որը որոնվածն արդեն հասկանում է։ Եթե կարողանաք այդ հատվածը սահմանել ձեր ունեցած երթուղիչում, ավելորդ տուփը լուծում է մի խնդիր, որը դուք չունեիք։
Առաջին մաս։ թունել, որը լռելյայն ուղին չէ
RouterOS-ում ավելացրեք կլիենտը առանց լռելյայն ուղու և տվեք թունելին իր աղյուսակը։ Առաջին ուղին նշված լռելյայնն է։ երկրորդը՝ ձախողման կեսը։
/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2
unreachable ուղին է պատճառը, որ նշված աղյուսակը հաղթում է հիմնական աղյուսակի բացառությունների ցանկին։ Երբ թունելն ընկնում է, նշված փաթեթները անմիջապես ստանում են unreachable՝ WAN-ին լուռ վերադառնալու փոխարեն, այնպես որ ձախողումը երևում է հավելվածի սխալի հաղորդագրության մեջ, ոչ թե աշխարհագրական դիրքի էջում, որը ստուգում եք մեկ ժամ անց։
RouterOS 7-ը բաժանում է այն, ինչ 6.x-ը միասին էր պահում։ աղյուսակը հռչակում եք /routing table add name=vpn fib-ով, ապա անունով հղում եք անում ուղու և mangle կանոնի մեջ։ 6.x-ի հատվածը, որը routing-mark-ը դնում է ներկառուցված՝ առանց աղյուսակը սահմանելու, մաքուր բեռնվում է և ոչնչի չի համապատասխանում։ Մյուս դասական դեպքը երկու 0.0.0.0/1 կեսերն են, կամ մեկ աղյուսակում նույն հեռավորության երկու լռելյայն ուղիներ։ միջուկն ընտրում է մեկը, և վարքը կարող է փոխվել վերագործարկումից հետո։
Երկրորդ մաս։ նշեք ուղու որոնումից առաջ
Ընտրիչը որոշում է, թե որ փաթեթներն են մտնում այդ աղյուսակ։ RouterOS-ը սովորաբար սկսում է նպատակակետի քաղաքականության համար հասցեների ցանկով, կամ սարքի քաղաքականության համար աղբյուրի հասցեով։
/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10
Linux որոնվածը նույնն է անում netfilter նշումով և կանոնով, որը նշված փաթեթներն ուղղում է ձեր լցրած աղյուսակ։
iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100
Շղթան ոճի ընտրություն չէ։ Երբ փաթեթը հասնում է FORWARD-ին, ուղու որոնումն արդեն կատարվել է, ուստի այնտեղ MARK-ը կամ DROP-ը կարող է միայն վերագրել կամ դեն նետել։ Նշումը պետք է ընկնի PREROUTING-ում փոխանցվող երթևեկության համար և OUTPUT-ում՝ երթուղիչի ինքնուրույն ստեղծած երթևեկության համար, քանի որ այնտեղ են ապրում երթուղիչի DNS-ը, NTP-ն և թարմացումների ստուգումները։ Հենց այդ ելքային ուղին է սովորական պատճառը, որ ամբողջությամբ թունելավորված կարգավորումը արտահոսքի փորձարկումում դեռ պատասխանում է ISP-ի լուծիչից։
Սարքի քաղաքականությանը պետք է համընկնում, որը չի սահում։ Ամրագրեք հասցեն DHCP-ում, կամ համապատասխանեցրեք ինտերֆեյսը հատուկ հատվածի համար։ ավելի ուշ այլ սարքի անցնող հասցեն լուռ կիրառում է թունելը սխալ կլիենտի վրա։ Յուրաքանչյուր SSID-ի կամուրջը սեփական ենթացանցով նույն գաղափարի ավելի դիմացկուն տարբերակն է, և այն IPv6 կանոններին տալիս է ապրելու տեղ։
Երրորդ մաս։ NAT, DNS և LAN բացառություն
Թունելով դուրս եկող երթևեկությանը պետք է աղբյուրի հասցե, որին կպատասխանի հեռավոր կողմը։ Սահմանափակեք թարգմանությունը թունելի ինտերֆեյսով։ out-interface=VPN_NAME RouterOS-ում, -o tun0 Linux-ում, համապատասխան ելքային NAT գրառում pfSense-ում։ Առանց այդ սահմանի masquerade կանոնը վերագրում է երթևեկություն, որը դուք մտադիր էիք թողնել առանց ուշադրության, և ախտանիշն այն է, որ չթունելավորված սարքը կորցնում է իր հանրային հասցեն։
LAN բացառությունը ավելի շատ աջակցության թելեր է առաջացնում, քան ինքը թունելը։ Եթե նշված աղյուսակը պարունակում է միայն լռելյայն ուղի, ընտրված սարքից տպիչի կամ NAS-ի նպատակակետը համընկնում է այդ լռելյային և անհետանում թունելում։ Ավելացրեք LAN ուղին նույն աղյուսակում, կամ բացառեք տեղական ենթացանցը ընտրիչում։ երկուսն էլ աշխատում են, և բացառությունը ավելի հեշտ է ճիշտ պահել, երբ ավելի ուշ ավելացնեք VLAN-ներ։
DNS-ը վերցնում է առանձին ուղի։ Երթուղիչի փոխանցած հարցումները ծագում են երթուղիչից և հետևում են OUTPUT-ին, ոչ թե փոխանցման նշմանը, ուստի ամբողջությամբ թունելավորված նոթբուքը դեռ կարող է լուծել ISP-ի միջոցով։ Ուղղեք կլիենտներին թունելով հասանելի լուծիչի, կամ նշեք երթուղիչի սեփական 53 պորտի երթևեկությունը, ապա ստուգեք լուծված հասցեն՝ փոխարենը ենթադրելու, որ պատասխանը ճամփորդել է վեբ հարցման հետ։
Երբ կանոնը համընկնում է, բայց հավելվածը դեռ օգտագործում է WAN-ը
Նպատակակետերի ցանկերը վատ են ծերանում։ Անունը լուծվում է հասցեի, որը ցանկում չկա, ուստի հարցումը վերցնում է WAN-ը, մինչ ցանկում նշված հասցեի դեմ ձեր բոլոր փորձարկումներն աշխատում էին։ Թարմացրեք ցանկը նույն լուծիչից, որն օգտագործում է կլիենտը, և երբ իսկապես ուզում եք մեկ սարքի ամբողջ երթևեկությունը, նախընտրեք աղբյուրի վրա հիմնված ընտրիչ։
IPv6-ը հանգիստ շրջանցումն է։ Սարքն ունի երկրորդ հասցեների ընտանիք իր լռելյայն ուղով և իր կանոնների հավաքածուով, և միայն IPv4 հասցեին համապատասխանելը կես քաղաքականություն է։ Կիրառեք նույն ընտրիչը ip6tables-ի կամ nftables-ի համարժեքի վրա, կամ դիտավորյալ անջատեք IPv6-ը այդ հատվածում, ոչ պատահաբար։
Հաստատված կապերն նույնպես կարևոր են։ Մինչ փոփոխությունը ստեղծված conntrack գրառումը հետևում է հին ուղուն մինչև ժամկետը լրանա, ուստի խմբագրման ընթացքում բաց մնացած զննարկիչը ճիշտ այնպիսի տեսք ունի, ինչպիսին կանոնը, որը երբեք չի կիրառվել։ Բացեք նոր կապ, կամ մաքրեք վիճակը, նախքան քաղաքականությունը գնահատելը։
Ստուգեք երկու սարքով և վերագործարկումով
Փորձարկեք այն սարքը, որը պետք է թունելում լինի, և այն, որը չպետք է, և համեմատեք երկրորդ ցատկը՝ արագության թվի փոխարեն։ traceroute-ը յուրաքանչյուրից ցույց է տալիս երկրորդ ցատկում կա՛մ թունելի դարպասը, կա՛մ ISP-ի դարպասը։ եթե երկուսն էլ նույն տեսքն ունեն, նշումը կամ աղյուսակը չի անում այն, ինչ ասում է կանոնը։ Փորձարկման համար օգտագործեք նոր կապեր։
Ապա վերագործարկեք։ Մեկնարկի հերթականությունը այն տեղն է, որտեղ աշխատող քաղաքականությունը դառնում է կոտրված, որովհետև կլիենտը պետք է միացած լինի նախքան unreachable ուղու տեղադրումը, և պահված պատկերը, որը վերականգնում է հին կանոնների հավաքածուն, կվերագրի ձեր աղյուսակը։ Ստուգեք, որ յուրաքանչյուր կանոն պահված կարգավորումում է, և նշված լռելյայնը գոյություն ունի բեռնումից հետո, ոչ միայն այն բանից հետո, երբ մուտքագրեցիք այն։
Եթե ինչ-որ բան ձախողվի, նախ հանեք նշումը և տեսեք՝ արդյոք նորմալ երթևեկությունը վերադառնում է, ապա հանեք աղյուսակը։ Այդ հերթականությունն ասում է՝ երթուղավորման խնդիր եք հետապնդում, թե ֆայրվոլի խնդիր, և տունը թողնում է աշխատող տպիչով, մինչ դուք ավարտում եք աշխատանքը։