VPN-ը և տնային LAN-ը նույն ենթացանցում են։ սկզբում անցեք երթուղին
Երկու ադապտերներն էլ հավակնում են 192.168.1.0/24-ին, և հաղթում է միայն մեկ երթուղի։ Անցեք ադապտերների ցանկը, հաղթող երթուղին և վերադարձի ուղին, նախքան վերահամարակալելը կամ DNS-ին մեղադրելը։
Դուք միանում եք գրասենյակի VPN-ին, սկուտեղի պատկերակը կանաչում է, ինտրանետը բեռնվում է, և երկու մետր հեռավորության վրա գտնվող տպիչը դադարում է պատասխանել։ Առավոտյան աշխատող համօգտագործվող պանակը ժամկետանցվում է նույն մեքենայի վրա, և ոչ մի մատյան տպիչ չի հիշատակում։ Առաջին արձագանքը DNS-ն է, որովհետև չլուծվող անունը նման է գոյություն չունեցող անվան, բայց խնդիրը հասցեի մեջ է՝ երկու ադապտեր այժմ հավակնում են 192.168.1.0/24-ին, և միայն մեկ երթուղի կարող է հաղթել այդ նախածանցը։ Անցեք այն այս հերթականությամբ և կտեսնեք, թե որ ադապտերն է վերցրել այն, նախքան որևէ բան փոխելը։
Սկսեք ախտանիշից, ոչ թե թունելից
Նշանը ծավալն է։ Եթե ինտրանետն աշխատում է, իսկ բոլոր տեղական սարքերը ձախողվում են, թունելը առողջ է, իսկ տեղական ուղին՝ ոչ։ Եթե տեղական սարքերն աշխատում են, իսկ ինտրանետը ձախողվում է, հակառակը։ Եթե ամեն ինչ աշխատում է բացի մեկ հոսթից, դուք տեսնում եք մեկ հասցե, որը գոյություն ունի երկու կողմերում։
Գրեք մեկ տեղական և մեկ հեռավոր հասցե, նախքան որևէ կարգավորում դիպչելը՝ «Տպիչը» ստուգելի չէ։ 192.168.1.40-ը՝ այո։ Այդ մեկ քայլը կանխում է այս խնդրի ամենահաճախ վատնված ժամը, այն է՝ DNS կարգավորումները վերաշարադրելը երթուղավորման որոշման համար։
Քայլ 1։ տեսեք երկու ադապտերները, որոնք հավակնում են նախածանցին
Բացեք Ցանցային միացումները (ncpa.cpl) և կողք-կողքի կարդացեք երկու ադապտերները։ Ethernet ադապտերը ցույց է տալիս 192.168.1.50/24՝ 192.168.1.1 դարպասով։ VPN ադապտերը ցույց է տալիս 192.168.1.201/24, որը սերվերն է ուղարկել։ Երկուսն էլ օրինական են, երկուսն էլ կարծում են, որ նախածանցը on-link է, և կույտը դրա համար կպահի մեկ երթուղի։
Get-NetIPAddress -AddressFamily IPv4-ը թվարկում է հասցեները, իսկ Get-NetIPInterface | Sort-Object InterfaceMetric-ը ցույց է տալիս այն հերթականությունը, որով կույտը կօգտագործի դրանք։ Այդ մետրիկայի սյունակը հենց այն որոշումն է, որը դուք պատրաստվում եք կարդալ, ուստի գրեք թվերը՝ փոխարենը մտապահելու փորձի։
Ապացուցեք էժանորեն, որ DNS-ի տեսությունը սխալ է՝ Resolve-DnsName printer.office.lan-ը վերադարձնում է նույն հասցեն, ինչ երեկ։ Անունը լուծվեց՝ փաթեթը հետո դուրս եկավ սխալ ադապտերով։ Այստեղ երկու րոպեն խնայում է կես օր լուծիչի կարգավորումներում։
Քայլ 2։ կարդացեք այն երթուղին, որն իրականում հաղթեց
Find-NetRoute -RemoteIPAddress 192.168.1.40-ը տպում է ինտերֆեյսը, հաջորդ ցատկը և աղբյուրը, որոնք կույտը կօգտագործեր այդ հասցեի համար։ Ընդունեք այդ ելքը որպես պատասխան, ոչ որպես ակնարկ։ route print -4-ը տալիս է ամբողջ աղյուսակը, երբ ուզում եք տեսնել, թե որ գրառումը պարտվեց և ինչքանով։
Յուրահատկությունը հաղթում է մտադրությանը։ Ուղարկված 192.168.0.0/25-ը հաղթում է տեղական 192.168.0.0/24-ին, որովհետև նախածանցն ավելի երկար է, ուստի 192.168.0.0-ից 192.168.0.127-ը դուրս են գալիս թունելով, մինչ վերին կեսը մնում է տեղական։ Կես LAN-ի անհետանալը՝ առանց սխալի հաղորդագրության, այդ աղյուսակի ճիշտ վարքն է։
tracert -d 192.168.1.40-ը հաստատում է դա աղյուսակից դուրս՝ եթե առաջին ցատկը թունելի հասցե է, այլ ոչ ձեր սեփական երթուղիչը, ապա երթուղին ամբողջ պատմությունն է։ Linux-ում նույն հարցը ip route get 192.168.1.40-ն է, որը տպում է աղբյուրի հասցեն և սարքը մեկ տողում։ Երբ պատասխանը նշում է tun0, դադարեք զննարկիչին նայել։
Քայլ 3։ ստուգեք վերադարձի ուղին, նախքան կլիենտին մեղադրելը
Ճիշտ ուղիղ երթուղին դեռ ձախողվում է, եթե հեռավոր կողմը չի կարող պատասխանել։ Երբ կլիենտի LAN-ին հասնում են թունելով, այդ LAN-ի դարպասը պետք է իմանա, թե որտեղ է ապրում թունելի լողավազանը՝ ip route add 10.8.0.0/24 via 192.168.1.12 այդ երթուղիչի վրա, և push «route 192.168.1.0 255.255.255.0» սերվերից, որպեսզի կլիենտները իմանան վերադարձի ուղին։
Առաջին գրառման բացակայության դեպքում պատասխանը թողնում է թիրախը՝ ուղղվելով իր լռելյայն դարպասին, որն անցնում է մասնավոր հասցեն մատակարարին և գցում այն։ Ախտանիշը միակողմանի է և հեշտ սխալ ընկալվող՝ հարցումները երևում են tun0-ում, պատասխանները՝ երբեք։
VPN հոսթի վրա masquerade կանոնը վերացնում է այդ ստատիկ երթուղու կարիքը՝ iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE։ Այն նաև թաքցնում է իրական աղբյուրի հասցեները, ինչը դժվարացնում է յուրաքանչյուր հետագա մատյանի հարց։ Սխալ լռելյայն դարպասով թիրախ հոսթը ստեղծում է նույն լռությունը՝ ICMP վերահասցեավորում լավագույն դեպքում և սև անցք սովորական դեպքում, այդ իսկ պատճառով որսումը պատկանում է երկու ծայրերին։
Քայլ 4։ ընտրեք ուղղում, որի հետ կարող եք ապրել
Դրա համար օգտագործվում է հինգ ուղղում, և դրանք փոխարինելի չեն։ Ընտրեք ըստ այն բանի, ինչը պետք է միաժամանակ հասանելի մնա, ոչ թե ըստ այն բանի, թե որ հրամանն է ամենակարճը։
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Մետրիկաները էժան տարբերակն են և այն, ինչին մարդիկ առաջինն են դիմում։ Փոփոխությունը վերաբերում է ինտերֆեյսին, ուստի աշխատում է, քանի դեռ թունելը վերևում է, և դրա տեղը կլիենտի կողքի սկրիպտում է, ոչ թե shell-ում, որը դուք կմոռանաք։ Այն չի կարող միաժամանակյա հասանելիություն տալ նույն հասցեին երկու ցանցերում, և հենց այդ սահմանն է, որ մնացած բոլորին ուղարկում է աղյուսակի ներքև։
Տնային LAN-ի վերահամարակալումը 10.10.0.0/24-ի մաքուր լուծումն է՝ DHCP վարձակալության մեկ նորացում՝ գումարած հին տիրույթը հիշատակող ամրագրումները, տպման հերթերը և կոշտ կոդավորված հասցեները։ Գրասենյակի կողմի վերահամարակալումը սովորաբար ձեր որոշումը չէ։ IPv6-ը ամբողջությամբ վերացնում է բախումը, երբ երկու ցանցերն էլ այն կրում են՝ օգտագործելով fd00::/8-ից եզակի տեղական նախածանց՝ հիշվող ինչ-որ բանի փոխարեն, բայց փորձարկեք հավելվածը TCP-ով, ոչ ping-ով, որովհետև ICMP-ն կարող է աշխատել, մինչ ծառայությունը՝ ոչ։
OpenVPN-ի սեփական թարգմանության ընտրանքը վերջին միջոցն է, որն ուղարկվում է սերվերից կլիենտին բնորոշ գրացուցակի գրառման մեջ՝ Այն ընտրանքի անունից հետո վերցնում է չորս պարամետր՝ ուղղություն, ցանց, ցանցային դիմակ և այլանուն, և այլանունը պարտադիր է։ push "route 192.168.2.0 255.255.255.0" և push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0"։ Ցանցն ու դիմակը այն տիրույթն են, որը տեսնում է կլիենտը (192.168.2.0/24), այլանունը սերվերի կողմի իրական գրասենյակային տիրույթն է (192.168.1.0/24), իսկ ուղարկված երթուղին այն է, ինչը հասանելի է դարձնում այդ տեսանելի տիրույթը։ Այնուհետև գրասենյակը այդ կլիենտին երևում է 192.168.2.x-ի ներքո։ Փաստաթղթավորեք քարտեզագրումը պրոֆիլում, այլապես հաջորդ մարդը կվրիպազերծի այն որպես երթուղավորման խափանում։
Մեկ ծառայության հրապարակումը թարգմանության նեղ տարբերակն է և ընդհանրապես OpenVPN-ի ընտրանքի կարիք չունի։ VPN հոսթի վրա DNAT կանոնը վերահրապարակում է մեկ պորտ, ուստի LAN-ը պահում է իր հասցեները և հասնում ծառայությանը այն հոսթ-հասցեով, որը նա արդեն գիտի։ Արժեքը սովորականն է՝ ծառայությունը VPN հոսթին տեսնում է որպես աղբյուր, ուստի ըստ կլիենտի մատյանները և հակադարձ որոնումները դադարում են նշանակություն ունենալուց։ Դա ընդգրկում է մեկ տպման հերթ կամ մեկ ադմինիստրատիվ էջ, ոչ թե երկու կողմերի հոսթերը, որոնք հասնում են միմյանց։
Ինչ դեռ չի աշխատի, և ինչ գրանցել
Հեռարձակումը չի անցնում երթուղավորված թունելով։ DLNA-ն, UPnP-ն, NetBIOS-ի դիտարկումը և Wake-on-LAN-ը կախված են հեռարձակումից կամ բազմահեռարձակումից, որը tun սարքը չի կրում, ուստի ոչ մի երթուղի չի շտկում հայտնաբերումը՝ dev tap-ով կամրջումը երկարացնում է սեգմենտը և նրա հետ՝ DHCP հեռարձակումները, ARP-ն և ցանկացած այլ հայտնաբերման փաթեթ։ նախապատվեք unicast հոսթ-երթուղուն, օրինակ route 192.168.2.1 255.255.255.255, հեռավոր երթուղիչի LAN-ի կողմի հասցեի համար։
Երկու երթուղիչ, որոնք երկուսն էլ օգտագործում են 192.168.1.1-ը նույն ուղու վրա, պատկանում են նույն խնդրի ընտանիքին՝ տեղական հասցեն միշտ հաղթում է, ուստի հեռավոր երթուղիչի էջը մնում է անհասանելի, քանի դեռ մի LAN չի տեղափոխվում։ Երկրորդ ադապտեր ավելացնելը ոչ մի դեպքում ոչինչ չի փոխում։
Գրանցեք ապացույցները, նախքան ինչ-որ բան խմբագրելը՝ ip route get կամ Find-NetRoute, ping -c 3 խնդրո առարկա հասցեին, traceroute, և tcpdump -ni tun0 icmp կլիենտի վրա, ապա երթուղավորման աղյուսակը և NAT հաշվիչները սերվերի վրա։ Ping-ը, որն աշխատում է մի ուղղությամբ և մահանում մյուսում, մատնանշում է վերադարձի ուղին, ոչ թե թունելը, և հենց այդ մեկ տարբերությունն է որոշում, թե վերևի ուղղումներից որն է ձեզ իրականում պետք։