80 և 443 պորտերի կանոնները բրաուզերը VPN-ով չեն ուղարկում
Պորտի համընկնումը ընտրում է TCP հոսքեր, ոչ բրաուզեր։ HTTP/3-ը աշխատում է UDP-ի վրա, DNS-ը կարող է այլ ուղի բռնել, և թարմացնողը համընկնում է ձեր գրած նույն կանոնին։
Ինչ-որ մեկը խնդրում է, որ բրաուզերն օգտագործի թունելը, և պատասխանը վերադառնում է որպես հրային պատի կանոն, որը համընկնում է նպատակակետ 80 և 443 պորտերին։ Այն ճշգրիտ է թվում և այդպիսին չէ։ Պորտի համընկնումը փաթեթներն ընտրում է ըստ տրանսպորտային վերնագրի, ոչ թե ըստ այն բանի, թե որ ծրագիրն է բացել սոքեթը, և ժամանակակից զննարկումը չի սահմանափակվում TCP-ի այդ երկու պորտերով։ Կանոնը բաց կթողնի ձեր ուզած որոշ երթևեկություն և կբռնի երթևեկություն, որը երբեք չէիք ուզում դիպչել։ Նախքան այն գրելը, որոշեք, թե երեք տարբեր սահմաններից որն եք իրականում ուզում։
Կանոնը նկարագրում է տրանսպորտի դաս, ոչ հավելված
Linux-ում նպատակակետ-պորտի համընկնումը զննում է TCP վերնագիրը և դրանից վեր ոչինչ։ Այդ փաթեթները նշելը և քաղաքականության ուղիով ուղղորդելը աշխատում է ճիշտ այնպես, ինչպես փաստաթղթավորված է, և այդ մեխանիզմներից ոչ մեկը չգիտի, թե ինչ է նշանակում բեռը կամ որ գործընթացն է այն ուղարկել։ Նշանը փաթեթին կցված թիվ է, ոչ թե հավելվածին կցված ինքնություն։
nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100Անմիջապես հետևում են երկու հետևանք։ Ծրագրային թարմացնողը, որը կապվում է TCP 443-ի հետ, ստանում է նույն վերաբերմունքը, ինչ բրաուզերը, ինչը կարող է լավ լինել կամ լինել ընդհատում, որը սպասում է հաջորդ թարմացման ցիկլին։ Եվ մեկ այլ պորտում դիտավորյալ հրապարակված վեբ ծառայությունը, ասենք 8443, ամբողջությամբ դուրս է մնում կանոնից, թեև դա դեռ այն վեբ երթևեկությունն է, որով հետաքրքրված էր օգտատերը։
Թվերը օրինական ընտրիչներ են, երբ պահանջը իսկապես այդ պորտերի մասին է։ Դրանք գեղարվեստական են դառնում, երբ տոմսում գրված է «բրաուզեր», իսկ կանոնների հավաքածուում իրականացված է պորտերի միջակայք։ Այդ ճեղքը փաստաթղթավորման մանրուք չէ։ Դա տարբերությունն է այն կանոնի միջև, որը կարող եք պաշտպանել վերանայման ժամանակ, և այն կանոնի, որը ոչ ոք չի կարող ստուգել։
HTTP/3-ը լուռ թողնում է ձեր TCP կանոնը
HTTP/3-ը աշխատում է QUIC-ի վրա, և QUIC-ը տեղափոխվում է UDP-ով։ Միայն TCP-ին համընկնող կանոնը չի կարող տեսնել այն, ուստի նույն բրաուզերը, որը բավարարում է ձեր փորձնական էջը, կարող է ավելի ուշ հարցում ուղարկել UDP-ով և շրջանցել թունելը՝ առանց որևէ մեկի պարամետր փոխելու։ RFC 9114-ը HTTP/3-ը նկարագրում է որպես QUIC-ի վրա հիմնված արձանագրություն, իսկ QUIC-ը սովորական տեղակայման մեջ օգտագործում է UDP՝ 443 լռելյայն պորտով։
Թե արդյոք տվյալ բրաուզերը կփորձի HTTP/3, կախված է նրա կարգավորումից, կայքից և այն բանից, թե արդյոք նախորդ փորձը հաջողվել է։ Դա այն դարձնում է վատ բան՝ հիշողությունից դատելու համար։ Փոխարենը հարցրեք գործիքին՝
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'curl տողը տպում է բանակցված տարբերակը, ուստի 3-ը հաստատում է, որ UDP ուղին օգտագործվել է։ Այնուհետև սոքեթների ցանկը ցույց է տալիս, թե արդյոք այդ կապը կապված է թունելի ինտերֆեյսի, թե ֆիզիկականի հետ։ Եթե ձեր curl կառուցվածքում HTTP/3 չկա, դրոշը բարձր ձախողվում է՝ լուռ հետ չնահանջելով, ինչը նրա սեփական փոքր ողորմությունն է։
DNS-ը առանձին որոշում է, որը դուք պետք է կայացնեք
Վեբ երթևեկության պորտի կանոնը ոչինչ չի ասում անունների լուծման մասին։ Բրաուզերը կարող է օգտագործել համակարգի լուծիչը, բրաուզերի ներսում կարգավորված լուծիչը կամ այն, որը մղել է վերջին միացումը։ Դրանցից յուրաքանչյուրը կարող է հարցումներ ուղարկել ձեր կանոնի ընտրածից տարբեր ուղիով, ինչը ստեղծում է դասական պառակտումը՝ էջը բեռնվում է, անունը լուծվում է մի տեղ, որտեղ չէիք սպասում, և ներքին կայքը լուծվում է հանրային հասցեի կամ ընդհանրապես չի լուծվում։
Որոշեք դա բացահայտ։ Եթե ներքին անունները պետք է լուծվեն թունելով, լուծիչը պետք է լինի դրա ներսում, և կանոնների հավաքածուն պետք է թույլատրի DNS դեպի այդ լուծիչը՝ դուրս պահելով մյուս հարցումները։ Եթե բրաուզերը հանրային մատակարարի հետ օգտագործում է DNS over HTTPS, հարցումը լիովին շրջանցում է ձեր լուծիչը, և պորտի կանոնը չի կարող օգնել։ Ընտրությունը գրեք նույն փոփոխության գրառման մեջ, ինչ երթուղավորման կանոնը, որովհետև երկուսն էլ միասին կարդում է նա, ով կվերացնի հաջորդ խափանումը։
Այնուհետև ստուգեք լուծիչով, ոչ էջով՝
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'Բացակայող պատասխանը լուծման խնդիր է նույնիսկ այն դեպքում, երբ բրաուզերի սխալի հաղորդագրությունը մեղադրում է ցանցին։ Այս երկու խափանումները օգտատիրոջը նույնն են թվում և բոլորովին տարբեր տոմսեր են։
Երեք սահման, երեք տարբեր մեխանիզմ
Խառնաշփոթի մեծ մասը վերանում է, հենց որ անվանեք ուզած սահմանը։ Դրանք փոխարինելի չեն, և յուրաքանչյուրն ունի ձախողման այլ եղանակ թունելի ընդհատման ժամանակ։
| What you actually want | Mechanism that fits | What it does not cover |
|---|---|---|
| These transport ports use this exit | Firewall mark plus policy route | Applications, HTTP/3 over UDP, DNS |
| This browsing session stays separate | Application-aware VPN, or a separate network namespace plus a proxy | Other applications in the same session |
| Only these private sites are reachable | Destination-based routes with private DNS | Public sites on the same address family |
Առանձին բրաուզերի պրոֆիլը միջին շարքի ծուղակն է։ Այն բաժանում է քուքիները և պատմությունը և ոչինչ չի փոխում հոսթի երթուղավորման աղյուսակում, ուստի երկու պրոֆիլներն էլ անցնում են նույն ուղիով։ Մեկուսացումը պահանջում է մի բան, որը պարտադրում է միջուկը, այսինքն՝ անունների տարածություն, կոնտեյներ կամ հավելված, որն ունի իր սեփական թունելի ինտերֆեյսը։
Որ տողն էլ վերաբերի, գրեք, թե ինչ պետք է լինի, երբ թունելն ընկնի։ Նշանի վրա հիմնված երթուղին, որը անհետանում է ինտերֆեյսի հետ, սովորաբար վերադառնում է ֆիզիկական լռելյայն երթուղուն, ինչը fail-open վարք է։ Դա կարող է ընդունելի լինել զննարկման և անընդունելի՝ մնացած ամեն ինչի համար, և դա որոշում է, ոչ թե իրականացման մանրուք։
Փորձարկեք այն հոսքերը, որոնք իբր ծածկում եք
Ընդունման փորձարկումը պետք է հետևի ձեր գրած սահմանին, ոչ թե հարմար պորտերի համարներին։ Ընտրեք մեկ հոսք, որը պետք է անցնի թունելով, մեկը, որը չպետք է, և մեկը, որն օգտագործում է տրանսպորտ, որի մասին չեք մտածել՝
ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'Երթուղու որոնումը ասում է, թե որ ինտերֆեյսն է իրականում օգտագործում նպատակակետը, և դա այն փաստն է, որը շատ զեկույցներ սխալ են նշում։ curl տողը հաստատում է բանակցված տարբերակը և հասցեների ընտանիքը։ Կանոնների հավաքածուի արտածումը բռնում է այն կանոնը, որը ավելացրել եք փորձարկման ընթացքում և մոռացել սահմանափակել, և այդպես է ժամանակավոր նշանը դառնում մշտական fail-open երթուղավորում։
Գրանցեք բոլոր երեք արտածումները ժամանակի դրոշմով և պահեք դրանք փոփոխության հետ։ Երբ ավելի ուշ ինչ-որ մեկը հայտնի, որ «VPN-ը կոտրել է ինտրանետը», նախատեսված և իրականացված սահմանի տարբերությունը տեսանելի կլինի այդ գրառման մեջ, և ուղղումը կանոնի փոփոխություն կլինի, ոչ թե վեճ։