Արդյո՞ք firewall-ը արգելափակում է VPN-ը։ Քայլ առ քայլ ստուգում

Մեկ VPN ժամանակի սպառումը ապացուցում է, որ օգտակար պատասխան չի եկել, և ոչինչ չի ապացուցում պատճառի մասին։ Պրոֆիլը կարող է նշել սխալ պորտ, սերվերը կարող է անջատված լինել, կամ հարցումը կարող է գալ առանց աշխատող վերադարձի ուղու։ Դրանցից յուրաքանչյուրը թողնում է տարբեր հետք, և հենց հետքն է ասում, թե որ կանոնին դիպչել։ Անցեք ներքևի չորս փուլերը հերթականությամբ։ Կանգ առեք հենց որ դրանցից մեկը բացատրի ախտանիշը։

Քայլ 1. հաստատեք սերվերը և տրանսպորտը

Կարդացեք սերվերի անունը, տրանսպորտը և պորտը օպերատորի ընթացիկ պրոֆիլից, ոչ թե տեղական փոփոխությունից։ Ձեր նոթբուքում փոփոխված պորտը չի կարող լսորդ ստեղծել հանրային սերվերի վրա, և այդ անհամապատասխանությունը տալիս է արգելափակմանը նույնական ժամանակի սպառում։ Եթե պրոֆիլը առաջարկում է աջակցվող այլընտրանքային տրանսպորտ, նշեք այն որպես պահուստ, ոչ որպես լուծում։ Լուծեք անունը և համեմատեք պատասխանը օպերատորի հրապարակած հասցեի հետ։

Հնացած DNS գրառումը հաճախորդին ուղարկում է հոսթ, որը երբեք չի պատասխանել։ Դա ևս մեկ խափանում է, որը նմանակում է զտիչին, և այն բացառելը մեկ հարցում արժե։

Գրեք երկու արժեքներն էլ տոմսի մեջ։ Յուրաքանչյուր հետագա համեմատություն օգտագործում է դրանք, և դրանցով տոմսը վերսկսում է հետաքննությունը։

Քայլ 2. ապացուցեք ուղին մեկ վերահսկվող համեմատությամբ

Թողեք սարքը և պրոֆիլը անփոփոխ և փորձեք մեկ այլ վստահելի մուտքի ցանց։ Եթե թունելը բարձրանում է այնտեղ, տարբերությունը սկզբնական ուղին կամ դրա քաղաքականությունն է։ Եթե երկրորդ հաստատված սարքը աշխատում է սկզբնական ցանցում, տարբերությունը առաջին սարքն է։ Այդ երկու համեմատություններից մեկը գրեթե միշտ վճռորոշ է։

Նախ ավարտեք ցանկացած օրինական ցանցային մուտքը, որովհետև գերեվարված պորտալը երևում է որպես արգելափակում, մինչև այն ավարտվի։

Փորձարկեք այն պորտը, որն իրականում օգտագործում եք, և TCP արդյունքը ընդունեք որպես տեղեկություն միայն TCP-ի մասին։

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

443 պորտում հաջող TCP ձեռքսեղմումը նշանակում է, որ լսորդն այնտեղ պատասխանել է։ Այն ոչինչ չի ասում 51820 պորտի UDP լսորդի մասին, ոչ էլ այն մասին, թե արդյոք բանակցությունը ավարտվել է։

Քայլ 3. կարդացեք անվտանգության իրադարձությունները խափանման պահի համար

Firewall-ի իրադարձությունները ամենաուժեղ ապացույցն են, և դրանք ունեն մի վերապահում, որն արժե նախ ասել։ Մատյանացումը անջատված է շատ լռելյայն պրոֆիլներում, այնպես որ ստուգեք, արդյոք համապատասխան պրոֆիլը գրանցում է թափումները, նախքան դատարկ մատյանը որպես անմեղության ապացույց կարդալը։ Երբ մատյանացումը միացած է, իրադարձությունը նշում է կանոնը, ուղղությունը և հասցեները, ինչը հենց այն է, ինչ պետք է կանոնի փոփոխությանը։ Հավելվածների կանոնները և պորտի կանոնները առանձին օբյեկտներ են, և կառավարվող քաղաքականությունը կարող է վերացնել տեղական կարգավորումը։ Հաստատեք, թե որ հաճախորդին և որ ծառայությունը կանոնն իսկապես ընդգրկում է։

Հավաքեք պրոֆիլի վիճակը և վերջին իրադարձությունները այն մեքենայից, որը ձախողվել է, ոչ թե հարևան հոսթից։

Համեմատեք իրադարձության ժամանակը ձեր փորձարկման ժամանակի հետ, որովհետև տարբեր ժամադրոշմով համընկնող կանոնի անունը պատահականություն է։

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

Ձեր կառավարած սերվերի վրա հարցրեք՝ արդյոք հարցումն ընդհանրապես հասել է լսորդին։ Առանց պատասխանի ժամանող փաթեթը փոխանցման կամ վերադարձի ուղու խնդիր է։ Հարցումը, որը երբեք չի հայտնվում, զտման կամ հասցեավորման խնդիր է։

Քայլ 4. փորձարկեք փոխանցումը թունելի բարձրանալուց հետո

Firewall-ը կարող է թույլատրել սեսիան և միևնույն ժամանակ մերժել այն ամենը, ինչին սեսիան ուզում է հասնել։ Փոխանցման sysctl-ները, NAT կանոնները և վերադարձի ուղիները բոլորն էլ նույնականացումից հետո են, և VPN պորտի լայն բացառությունը չի վերականգնում դրանցից ոչ մեկը։ Փորձարկեք մեկ ներքին նպատակակետ և մեկ ինտերնետ նպատակակետ առանձին, որովհետև դրանք սովորաբար ձախողվում են տարբեր պատճառներով։ Եթե ներքին անունները ձախողվում են, բայց հասցեները աշխատում են, նայեք հրող DNS-ին ցանկացած կանոնից առաջ։

Գործարկեք ներքևի երեք ստուգումները սերվերի վրա, մինչ հաճախորդը միացված է և փորձում է ձախողվող հարցումը։

Թունելի ինտերֆեյսի հաշվիչներն են էականը, որովհետև դրանք ցույց են տալիս՝ փաթեթները մտե՞լ են, և ինչ-որ բան դուրս եկե՞լ է։

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Երբ փաթեթները ժամանում են թունել և ոչինչ չի դուրս գալիս դեպի նպատակակետ, կասկածյալը փոխանցումն է կամ NAT-ը։ Երբ ոչինչ չի ժամանում, սեսիան բարձրացած է, բայց հաճախորդը չի ուղարկում, և նայելու տեղը հաճախորդի երթուղիների աղյուսակն է։

Ստուգեք ուղղումը և հեռացրեք այն, ինչը չօգնեց

Հաստատված ուղղումից հետո կրկնեք ճիշտ այն փորձարկումը, որը ձախողվել էր, և գրանցեք արդյունքը նույն պրոֆիլի և սարքի դեմ։ Ապա հեռացրեք ցանկացած ժամանակավոր բացառություն, որը չի փոխել արդյունքը, որովհետև չօգտագործված բացառությունները կուտակվում են, և յուրաքանչյուրը որոշում է, որը ոչ ոք չի հիշում։ Պահեք մնացածը նեղ՝ մեկ նպատակակետ, մեկ պորտ, մեկ ուղղություն, մեկ պատասխանատու։

Կրկին գործարկեք նույն երեք հրամանները և համեմատեք դրանք փոփոխությունից առաջ պահված արտածումների հետ։

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

Երբ համեմատության ցանցը աշխատում է, սկզբնական ցանցը դեռ ձախողվում է, և իրադարձությունները մնում են դատարկ, մնացած կասկածյալը ուղին է, ոչ թե հոսթը։ Փոխանցեք դա ցանցի սեփականատիրոջը որպես կոնկրետ պնդում՝ կցելով երկու համեմատության արդյունքները։ Սա ավելի լավ կանգառ է, քան անջատված firewall պրոֆիլը։