Ո՞ր աղբյուրի հասցեն NGINX-ը կգրանցի VPN հաճախորդի համար։
Որոշեք, թե ինչ է տեսնում NGINX-ը OpenVPN-ի կողքին մեկ հոսթում՝ ներքին թունելի հասցե, հանրային ելքի հասցե թե փոխանցված զուգընկեր՝ կախված անցած ուղուց։
Նույն հոսթում NGINX-ի և OpenVPN-ի կարգաբերման մեջ հայտնվում են երեք հաճախորդի հասցեներ՝ մեկը յուրաքանչյուր ուղու համար, որով կարող է գնալ հարցումը։ Թունելի հասցեին հասնող դիտարկիչը, հանրային հասցեին հասնող դիտարկիչը և դարպասի ինտերնետ ուղով դուրս եկող ծրագիրը լսող սոքեթում տարբեր տեսք ունեն։ Նախքան մատյանային տողը մեկնաբանելը որոշեք, թե որ ուղին եք նայում։ Որոշումը կախված է հաճախորդի օգտագործած նպատակակետից, արտաքին VPN վերջնակետի համար նրա պահած բացառությունից և նրանից՝ արդյոք ինչ-որ բան ուղու վրա թարգմանում է փաթեթը։
Որոշեք ըստ նպատակակետի, ոչ թե ըստ այն բանի, թե ով է օգտվողը
Սկսեք այն հասցեից, որին ուղարկվել է հարցումը, որովհետև այդ հասցեն է ընտրում ուղին։ Հոսթի թունելի հասցեին ուղղված հարցումը հասնում է թունելի ինտերֆեյսին՝ հաճախորդի ներքին հասցեն որպես աղբյուր։ Հոսթի հանրային հասցեին ուղղված հարցումը սովորաբար հասնում է դեպի ինտերնետ ուղղված ինտերֆեյսին՝ հաճախորդի հանրային հասցեով, նույնիսկ երբ նույն նոթբուքն այդ պահին թունել ունի հաստատված։ Ուստի VPN լողավազանին անդամակցությունը փաթեթի ուղու հատկություն է, ոչ թե օգտվողին հետևող հատկություն։
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
Հենց այդ երրորդ տողն է, որ արժե առաջինը ստուգել, երբ մատյանում հայտնվում է VPN օգտվող թունելի հետ որևէ կապ չունեցող հասցեով։ Այն նաև բացատրում է, թե ինչու միևնույն պրոֆիլի երկու օգտվող կարող են տարբեր գրառումներ ստեղծել՝ նրանց սեփական մուտքի ցանցերը տարբեր են, և թունելում ոչինչ դա չի վերագրում։
Ինչու արտաքին վերջնակետը ստեղծում է երկրորդ հանրային ուղի
Հաճախորդը պետք է հասնի դարպասի հանրային հասցեին՝ թունելը հաստատելու համար, ուստի այդ հասցեին տանող ուղին պետք է գոյություն ունենա թունելից դուրս։ Երբ հաճախորդը շրջում է ամբողջ երթևեկությունը դեպի ներս, խելամիտ իրականացումը պահում է սերվերի հանրային հասցեի բացահայտ հոսթ-ուղի՝ ինքն իրենից կախված թունելից խուսափելու համար։ Այդ բացառությունը ծառայությունների առումով ընտրովի չէ, ուստի նույն հանրային հասցեին ուղղված ցանկացած հարցում հետևում է դրան, ներառյալ դարպասում հյուրընկալված կայքի դիտարկիչի հարցումը։
Սա այն մեխանիզմն է, որ ընկած է այս բնագավառի ամենաշատ շփոթեցնող զեկույցների հիմքում, և այն կախված է հաճախորդի, ոչ թե սերվերի իրականացումից։ Ուստի նույնական պրոֆիլներով երկու հաճախորդ կարող են տարբեր վարվել։ Բացառությունը հեռացնելը՝ մատյանը »ուղղելու« համար, թունելն էլ է գցում, ուստի պահեք այն և նախագծեք դրա շուրջ։
Կարդացեք սոքեթը, աղյուսակը և մատյանի ձևաչափը միասին
Երեք դիտարկում որոշում են, թե որ ուղին եք նայում՝ որտեղ է լսում սոքեթը, որ ինտերֆեյսն է պատասխանում նպատակակետին, և ինչ է իրականում գրանցում մատյանի ձևաչափը։ Եթե լսողը կապված է միայն թունելի հասցեին, հանրային հարցումն ընդհանրապես չի կարող հասնել դրան, ինչը անմիջապես բացառում է երկու տող։ Եթե հաճախորդի որոնումը վերադարձնում է թունելի սարքը, հարցումը եկել է ներքին աղբյուրով, և մատյանը պետք է դա ցույց տա։
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44Ապա կարդացեք ձևաչափը, ոչ թե տողը։ Փոխանցված վերնագրով սնվող դաշտը գրանցում է պնդում, ոչ թե սոքեթի զուգընկեր, և պնդումը նշանակություն ունի միայն այն ժամանակ, երբ անմիջական զուգընկերը վստահելի պրոքսի է։ Երկու արժեքներն էլ մատյանում գրելը լուծում է հետագա վեճերը, որովհետև անմիջական զուգընկերը և փոխարինված հասցեն տարբեր փաստեր են, և դրանցից միայն մեկն է եկել ցանցից։
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confԸնտրեք ցանկալի մուտքի կետը և համաձայնեցրեք DNS-ը
Եթե կայքը պետք է լինի միայն թունելով, տվեք նրան անուն, որը VPN հաճախորդների համար լուծվում է թունելի հասցեի, և կիրառեք քաղաքականություն լսող սոքեթում։ Ներքին անվան համար 10.24.0.1 վերադարձնող բաժանված DNS պատասխանը երթուղավորման որոշում է՝ անվան լուծման մանրամասնության զգեստով։ Եթե կայքը պետք է լինի նաև հանրային, պահեք երկու անուն կամ երկու պորտ և թույլ տվեք մատյանին ասել, թե որն է սպասարկել հարցումը։
Թույլտվության կանոնները հետևում են նույն տրամաբանությանը։ Թունելի լողավազանը թույլատրելը չի լիազորում հանրային հարցում և չի լրացնի ներքին հասցե ինտերնետով եկած կապի վրա։ Երկու մուտքի կետերը մեկ անվան տակ խառնելը գրանցված աղբյուրը դարձնում է հաճախորդի երթուղավորման կողմնակի ազդեցություն՝ նախագծային ընտրության փոխարեն։
Ստուգեք ուղին, ապա քաղաքականությունը
Հաստատեք ուղին դարպասում արված որսով և ձեր վերահսկած հարցումով։ Թունելի սարքում արված որսը և հանրային ինտերֆեյսում արվածը ցույց են տալիս, թե որն է տարել բայթերը, և փաթեթների հերթականությունը ասում է՝ արդյոք նրանց միջև թարգմանություն եղել է։
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5Ապա ստուգեք հասանելիությունը երկու ուղղությամբ՝ նախատեսված անվանված մուտքը աշխատում է նախատեսված հաճախորդի համար, և չհաստատված հանրային ուղին մերժվում է, ոչ թե պարզապես դանդաղ է։ Ընդհանուր IP-արձագանքի կայքը ինչ-որ բան ապացուցում է դարպասի ինտերնետ ելքի մասին և ոչինչ՝ նույն հոսթի այս կայքի մասին։ Երբ էջը և WebSocket-ը չեն համաձայնում, համեմատեք դրանց URL-ները, հասցեների ընտանիքները և DNS պատասխանները նախքան սերվերի կարգավորումը դիպչելը։