UFW-ը թողնում է VPN-ի DNS սերվերը, հենց որ թունելը բարձրանում է
UFW-ի լռելյայն մերժման քաղաքականությունը ծածկում է նաև թունելի ինտերֆեյսը։ Տրաֆիկը դասավորիր ուղղությամբ, թույլատրիր հրված լուծիչը tun0-ի վրա, ապա բացիր արտաքին ուղին։
Անունները դադարում են լուծվել այն պահին, երբ VPN-ը միանում է, մինչդեռ հանրային հասցեին ping-ը դեռ պատասխանում է, և firewall-ի կարգավիճակը ոչ մի սխալ բան չի ցույց տալիս։ Քաղաքականության մեջ ոչինչ չի փոխվել. փոխվել է այն, որ նոր ինտերֆեյս է հայտնվել, և լռելյայն մերժումը ծածկում է այն առաջին փաթեթից։ UFW-ը որոշում է ուղղությամբ և ինտերֆեյսով, ուստի անլար կապի համար գրված կանոնը ոչինչ չի ասում թունելից դուրս եկող տրաֆիկի մասին։ Վերանորոգումը մի բուռ նեղ կանոններ են՝ կիրառված որոշակի հերթականությամբ։
Ախտանիշը հայտնվում է միայն այն բանից հետո, երբ թունելը բարձրացել է
Լռելյայն մերժման քաղաքականությունը անում է հենց այն, ինչ իրեն ասել են. ամեն ինչ, ինչը համապատասխան կանոն չունի, մերժվում է, գոյություն ունեցող յուրաքանչյուր ինտերֆեյսի վրա։ Թունելը գոյություն չուներ, երբ գրվում էին կանոնները, ուստի նրանցից ոչ մեկը չի կարող բռնել այն, և այն մերժումը, որը միշտ այնտեղ էր, այժմ տարածվում է անունների լուծման վրա։ Ուղիղ տրաֆիկը դեպի բառացի հասցե դեռ կարող է աշխատել, երբ ավելի լայն թույլտվություն է ծածկում այն, և դրա համար է, որ հանրային լուծիչին ուղղված ping-ը հաջողվում է, մինչդեռ անվան որոնումը ձախողվում է։ Բացը կանոնն է մի ինտերֆեյսի համար, որը քաղաքականությունը երբեք չի տեսել։
Դա նաև բացատրում է, թե ինչու ձախողումը մաքուր կերպով շրջվում է. իջեցրու թունելը և անունները նորից լուծվում են, որովհետև հարցումը վերադառնում է մի ինտերֆեյս, որն ունի կանոններ։ Քաղաքականությունը, որը ձախողվում է միայն թունելի բարձրացած ժամանակ, DNS խնդիր չէ, և հենց լուծիչը կարգավորելը այստեղ ամենաշատ ժամանակն է վատնում։ Կարդա ինտերֆեյսների ցանկը նախքան լուծիչի կոնֆիգուրացիան կարդալը։
Երեք ուղղություն, երեք տարբեր կանոնների հավաքածու
Մեկ սեսիան դիպչում է կանոններին մեկից ավելի ուղղությամբ, և թունելը երկրորդ ինտերֆեյս է ավելացնում դրանցից գրեթե բոլորին։ Տրաֆիկը նախ ուղղությամբ և ինտերֆեյսով դասավորելը մնացածն անում է մեխանիկական, որովհետև ներքևի յուրաքանչյուր տող իր տեղում իր կանոնն է պահանջում։ Օրինակները օգտագործում են tun0 և 10.8.0.0/24 լողավազան, ուստի փոխարինիր անուններն ու միջակայքերը հաճախորդի սեփական ելքի հետ։
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
Երկու տող հաճախ շփոթում են, որովհետև երկուսն էլ հիշատակում են թունելը։ Լուծիչի կանոնը թույլատրում է տրաֆիկը, որը հաճախորդն ուղարկում է թունել, մինչդեռ SSH-ի կանոնը թույլատրում է տրաֆիկը, որը սերվերը ստանում է դրանից. դրանք ապրում են տարբեր մեքենաներում և ձախողվում են անկախ։ Ամենահաճախ մոռացվող տողը երկրորդն է, որովհետև հաճախորդը բոլորովին չի կարող կառուցել թունելը, քանի դեռ սերվերի հանրային հասցեին նրա տրաֆիկը թույլատրված չէ։ Աշխատիր վերևից ներքև, և յուրաքանչյուր ձախողում ունի մեկ հավանական պատճառ։
Հրված լուծիչն իր կանոնի կարիքն ունի
Թունելը DNS է տանում, թե ոչ, կախված է նրանից, ինչ ուղարկում է սերվերը։ Սերվերը, որը հրում է լուծիչի ընտրանք, հաճախորդի կոնֆիգուրացիայում տեղադրում է մասնավոր հասցե, և այդ հասցեն երթուղվում է միայն թունելով։ Եթե սերվերը ոչինչ չի հրում, հաճախորդը պահում է այն լուծիչը, որն արդեն ուներ, և ներքևի կանոնները թույլատրելու բան չունեն։ Նախքան որևէ բան գրելը ստուգիր հրված վիճակը և ընթացիկ հարցման արդյունքը:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedԿարգավիճակի ելքը նշում է օգտագործվող լուծիչը և այն կապը, որին այն կապված է, իսկ դրա հետևում եղած երթուղու որոնումը ցույց է տալիս, թե որ ինտերֆեյսը կտանի հարցումը այդ հասցեին։ Երբ լուծիչը նստած է այլ կապի վրա, խնդիրը firewall-ից ավելի վաղ է, և ոչ մի կանոն չի օգնի։ Երբ երկուսը համաձայն են թունելի շուրջ, երկու կանոն է պետք, որովհետև հարցումների մեծ մասը UDP-ն է տանում, իսկ TCP-ն ստանձնում է, երբ պատասխանը կտրվում է։ Գրիր երկու արժեքներն էլ, որովհետև հենց դրանք են, որ կանոնները կնշեն:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'Բացիր արտաքին ուղին ներքինից առաջ
Հաճախորդը պետք է հասնի սերվերի հանրային հասցեին նախքան թունելի գոյությունը, ուստի դրա կանոնը նստած է ֆիզիկական կապի վրա և պետք է առաջինը լինի իր տեղում։ Քաղաքականությունը, որը թույլ է տալիս լուծիչին, բայց մոռանում է սերվերը, հաճախորդին թողնում է բոլորովին ի վիճակի չէ կառուցել թունելը, և այդ ախտանիշը սովորաբար վերագրվում է kill switch-ին։ Ապա թույլատրիր այն ծառայությունները, որոնք իսկապես ուզում էիր թունելով, միաժամանակ մեկ նեղ կանոն, ինտերֆեյսն ամբողջությամբ բացելու փոխարեն։ Նեղ կանոններն են պատճառը, որ մերժումը կարող է մնալ իր տեղում։
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'Հերթականությունը կարևոր է փորձարկելիս, որովհետև առաջին կանոնն է, որ ընդհանրապես թույլ է տալիս թունելին բարձրանալ։ Ավելացրու այն, միացիր և հաստատիր, որ թունելը բարձրացել է, նախքան ծառայության կանոնը ավելացնելը, որովհետև երկուսն էլ միաժամանակ անելը նշանակում է, որ ձախողումը ոչինչ չի ասում, թե որ կեսն է սխալ։ Փոխարինիր վերևի փաստաթղթային հասցեն այն վերջնակետով, որի համար կարգավորված է հաճախորդը։
Ավարտիր հաճախորդի կողմը դիտավորյալ անջատվելով։ Մերժումը պետք է դեռ մերժի այն տրաֆիկը, որը դու դիտավորյալ բացառեցիր, որովհետև լուծիչը, որը պատասխանում է, երբ թունելը բարձրացած է, ծածկում է կասկածի դեպքում մերժող քաղաքականության միայն կեսը։
Միացող հաճախորդը դեռ ընդունված չէ
Սերվերն ունի իր ուղղությունը հաշվի առնելու, և ձեռքսեղմումը ավարտող հաճախորդը դեռ չի հասնում սերվերի վրա աշխատող ոչ մի բանի, քանի դեռ սերվերը չի ընդունել նրան։ Հանրային լսողի կանոնը միայն թույլ է տալիս թունելի գոյությունը. այն ներս չի թողնում թունելի տրաֆիկը։ Սերվերի վրա դա երկու կանոն գումարած մեկ ստուգում է, որ ծառայությունն իրոք լսում է:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'Կանոնի լողավազանը պետք է հավասար լինի այն միջակայքին, որը սերվերը հատկացնում է, և թունելի համարը պետք է համապատասխանի սերվերի ստեղծածին, որովհետև այլ ինտերֆեյսի կանոնն անտարբերելի է կանոնի բացակայությունից։ limit դիտավորյալ է ադմինիստրատիվ պորտի համար, որովհետև այն սահմանափակում է կրկնվող միացումները անսահմանափակ ընդունելու փոխարեն։ Լսողի ստուգումը տարբերում է փակ պորտը գցված փաթեթից, որոնք հաճախորդի կողմից նույնն են երևում։ Համարակալված կանոնները նույնպես ամբողջ պատկերը չեն. UFW-ի before կանոնները և ձեռքով գրված ցանկացած nftables տող ավելի վաղ են համապատասխանում և դեռ կարող են մերժել փաթեթը, որը ցանկը կարծես թույլատրում է։