Ինչ է բացահայտում STUN պատասխանը, երբ VPN-ը աշխատում է երթուղիչի վրա
Երթուղիչի թունելի հասցեն դիտարկիչի տեղական հասցեն չէ։ Հետևեք, թե ինչպես է յուրաքանչյուր հարցում երթուղվում և թարգմանվում, նախքան կարդալը, թե ինչ է հաղորդում արտացոլիչը։
Երբ թունելը գտնվում է երթուղիչի վրա, դիտարկիչը գործարկող մեքենան ընդհանրապես թունելի ինտերֆեյս չունի։ Հարցրեք այդ մեքենային նրա տեղական հասցեները և կստանաք մասնավոր LAN հասցե և հետադարձ հանգույց՝ ոչինչ, որ նման լինի VPN հասցեի։ Այնուամենայնիվ, մյուս կողմի STUN սերվերը դեռ կարող է ինչ-որ իմաստալից բան հաղորդել ուղու մասին, և այն, ինչ նա հաղորդում է, ամբողջությամբ կախված է նրանից, թե ինչպես է այդ կոնկրետ հարցումը երթուղվել և թարգմանվել։
Հենց այս մասն է արժանի դանդաղելու։ «Դիտարկիչը VPN հասցեի սեփականատերը չէ» արտահայտությունը պատասխանում է ինտերֆեյսների մասին հարցին, մինչդեռ արտացոլված հասցեն պատասխան է թարգմանության միջով անցնող ուղու մասին։ Երկուսը շփոթելը ծնում է բացահայտման մասին վստահ եզրակացություններ, որոնք ապացույցները չեն հաստատում։
Երկու սարք, ինտերֆեյսների երկու հավաքածու
Երթուղիչի վրա հիմնված կարգավորման դեպքում թունելը ավարտվում է երթուղիչի վրա, և LAN հաճախորդը սովորական երթևեկությունն ուղարկում է իր լռելյայն դարպասին։ Հաճախորդի ինտերֆեյսների ցանկը մնում է կարճ՝ մեկ մասնավոր հասցե, գուցե երկրորդը այլ ցանցի համար, և հետադարձ հանգույցը։ Ռիսկը ոչ թե նրանում է, որ դրանցից մեկը պատահաբար թունելի հասցեն է, այլ նրանում, որ հարցումը դուրս է գալիս ձեր չընտրած ուղով։
Հարցրեք հաճախորդին թե որ ուղին կընտրի կոնկրետ նպատակակետը՝ փոխանակ հարցնելու, թե ինչ ինտերֆեյսներ գոյություն ունեն։ Պատասխանը նշում է դարպաս և աղբյուրի այն հասցեն, որը կօգտագործեր միջուկը, և դա արդեն ավելի տեղեկատվական է, քան հասցեների ցանկացած ցանկ։
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsՓաստաթղթային տիրույթները լավ փորձարկման նպատակակետեր են, քանի որ երբեք չեն լուծվում իրական ծառայության։ Համեմատեք, թե ինչ է ասում հաճախորդը նրա հետ, թե ինչ է ասում երթուղիչը, և ցանկացած անհամապատասխանություն ընդունեք որպես ապացույց, որ քաղաքականության երթուղումը, բաժանված թունելի կանոնը կամ երկրորդ լռելյայն ուղին անում է մի բան, որը հաշվի չեք առել։
Ինչ է թույլատրվում ասել Binding պատասխանին
RFC 8489-ը սահմանում է Binding հարցումն ու պատասխանը, որտեղ սերվերը հաղորդում է այդ հարցման համար իր դիտած աղբյուրի փոխադրման հասցեն։ Սա հայտարարություն է մեկ հնգյակի մասին մեկ պահին, ոչ թե հաճախորդի ինտերֆեյսների մարդահամար։ Ուստի ամեն հետաքրքիր բան տեղի է ունենում հաճախորդի և դիտարկման կետի միջև։
Այդ բացը լրացնում են երթուղումը և թարգմանությունը։ Երթուղիչը, որը ելքային երթևեկության համար կատարում է աղբյուրի NAT, փոխարինում է հաճախորդի մասնավոր աղբյուրը իր իսկ հասցեով ելքային ինտերֆեյսի վրա։ Եթե այդ ինտերֆեյսը թունելն է, արտացոլիչը տեսնում է թունելի հասցեն։ Եթե փաթեթը բացառվել է թունելից, արտացոլիչը տեսնում է այն, ինչ ստեղծել է WAN թարգմանությունը։ Նույն հաճախորդը, նույն արտացոլիչը, այլ պատասխան։
Երեք դեպք, որոնք նման են և այդպիսին չեն
Օգտակար տարբերությունը ոչ թե հանրայինն ընդդեմ մասնավորի է, այլ այն, թե որ կիրարկման կետն է զբաղվել փաթեթով։ Անցեք դեպքերը երթուղիչի սեփական աղյուսակներով բացված, քանի որ մեկ դիտարկիչ կարող է առաջացնել բոլոր երեքը՝ կախված մի կանոնից, որը մոռացել եք, որ գրել եք։
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Միայն երկրորդ դեպքն է խախտում այն պահանջը, որ որոշակի երթևեկություն երբեք ուղղակիորեն դուրս չգա, և միայն առաջինն ու երրորդն են բացահայտում թունելի կողմի նույնացուցիչ։ Երեք տողերից ոչ մեկը պնդում չէ կոնկրետ մատակարարի վարքի մասին. թե արդյոք մասնավոր արտացոլիչն ընդհանրապես հասանելի է, կախված է երթուղումից, մյուս կողմի թույլատրված IP հասցեներից և երկու ծայրերի հրապարակարգի քաղաքականությունից։
Նույն մատակարարի մոտ հաշիվ ունենալը դրանից ոչինչ չի հաստատում։ Արժե նաև հիշել, որ երթուղված հարցումը կարող է պահպանել հաճախորդի LAN աղբյուրը, եթե ոչինչ չի թարգմանում այն, ուստի աղբյուրի դաշտը պետք է հետևել, այլ ոչ թե ենթադրել տոպոլոգիայի գծապատկերից։
Հավաքելը ընտրել չէ
WebRTC-ն հավաքում է թեկնածու հասցեներ փորձարկելու համար, և ախտորոշիչ ցանկում հայտնված թեկնածուն կարող է երբեք մեդիա չկրել։ Ցանկը որպես «այս է, ինչ սովորել է մյուս կողմը» կարդալը գերագնահատում է ապացույցը։ Ընտրված զույգն այն է, ինչն իրականում կրում էր նստաշրջանը, և այն ապրում է այլ դաշտում։
HTTPS ելքի ստուգիչը պատասխանում է ևս մեկ հարցի՝ այն աղբյուրի հասցեին, որը վեբ սերվերը տեսել է այդ հարցման համար։ Սա օգտակար խաչաձև ստուգում է հենց այն պատճառով, որ օգտագործում է այլ արձանագրություն և հաճախ այլ նպատակակետ, քան UDP արտացոլիչը, և երկուսի միջև անհամապատասխանությունը սովորաբար մատնանշում է երթուղման կանոն, ոչ թե սխալ։
Որոշեք քաղաքականությունը, ապա կարդացեք պատասխանը
Փորձարկումից առաջ գրի առեք մտադրությունը՝ որ երթևեկությունը պետք է օգտագործի թունելը, որը կարող է ուղղակիորեն դուրս գալ, որ հասցեների ընտանիքներն են ընդգրկված, և ինչ պետք է տեղի ունենա, երբ թունելն անջատված է։ Առանց այդ հիմքային գծի յուրաքանչյուր դիտարկում երկիմաստ է, քանի որ չեք կարող առանձնացնել արտահոսքը ձեր գիտակցաբար թույլատրած ուղուց։
Ապա հարցրեք մեկ հարց միաժամանակ։ Որ ուղին է վերցնում այս նպատակակետը։ Որ հասցեն է հաղորդում այս արտացոլիչը։ Որ թեկնածու զույգն է ընտրել նստաշրջանը։ Պահեք պատասխանները քաղաքականության կողքին և թվագրեք դրանք, քանի որ որոնաշերտի թարմացումը կարող է փոխել լռելյայն վարքը այնպես, որ լուռ անվավեր դարձնի անցյալ տարվա եզրակացությունը։
Երթուղիչը դեռ ուժեղ կիրարկման կետ է, քանի որ տեսնում է երթևեկություն, որը հաճախորդը չի կարող շրջանցել առանց ինքն իրեն վերակարգավորելու։ Սա խոստում չէ, որ ամեն հավելվածային արձանագրության ամեն դաշտ ոչինչ չի բացահայտում, և փոխարինում չէ ձեր թույլատրել ընտրած ուղիները գրի առնելուն։