Բոլոր պորտերը փոխանցող կանոնը կարող է կուլ տալ ձեր WireGuard-ի լսողին
Լայն փոխանցման կանոնը կարող է կուլ տալ դարպասի սեփական WireGuard և SSH լսողներին։ Ընտրեք նեղ կանոններ կամ առանձին հանրային հասցե, ապա ստուգեք կառավարման ուղին։
Հանրային դարպասն արդեն աշխատում է WireGuard UDP 51820-ով, SSH 22-ով և մեկ հավելվածով, որը պետք է հասանելի լինի ինտերնետից։ Գայթակղիչ կանոնը փոխանցում է բոլոր պորտերը դեպի զուգընկերը և համարում գործը ավարտված։ WireGuard դարպասի վրա նման կանոնը կարող է գրավել թունելի սեփական տրանսպորտը և ձեզ դուրս թողնել այն մեքենայից, որը վերջացնում է այն։ Հրապարակումը երթուղային որոշում է՝ կառավարման հարթության բացառությամբ, ոչ թե մեկ DNAT տող։
Հանրային մուտք, թունելի մուտք՝ ընտրեք մեկը
Ծառայության հրապարակումը ստեղծում է ինտերնետ մտնելու նոր կետ։ Դա նույնը չէ, ինչ զուգընկերոջը VPN անդամակցություն տալը, քանի որ այցելուն երբեք չի մտնում թունել և դարպասը դառնում է բեքենդի հանրային դեմքը։ Այդ տարբերությունը որոշում է կանոնի լսարանը և դրա վկայականը։
Վարչական ինտերֆեյսները հազվադեպ են տեղավորվում այդ դիրքում։ Լիազորված VPN հաճախորդների հասանելի ադմինիստրատիվ էջը պահում է հարձակման մակերեսը թունելի ներսում և խուսափում է մուտքի ձևը կամայական սկանավորման ենթարկելուց։ Հանրային հավելվածի վերջնակետերը դեռ պետք է ունենան իրենց TLS վկայականը, նույնականացում և արագության սահմանափակում․ գաղտնագրված WireGuard քայլը չի պաշտպանում այցելուի հատվածը մինչև դարպասը։
Եթե ծառայությունը իսկապես պետք է հանրային լինի, գրեք հոսթի անունը, այն վկայականը, որը ծածկում է այն, և այցելուների այն միջակայքերը, որոնք պետք է հասնեն դրան։ Այդ երեք փաստերը հետագայում որոշում են կանոնի ձևը և զտիչ քաղաքականությունը։ Դրանցից դուրս ամեն ինչ շրջանակի ընդլայնում է հանրային լսողի վրա։
Մեկ պորտ ներս, մեկ բեքենդ դուրս
Օգտագործեք մեկ հանրային պորտ և մեկ բեքենդ ծառայություն։ Այս օրինակում eth0-ը կրում է հանրային 198.51.100.20 հասցեն, դարպասի թունելի հասցեն 10.200.0.1-ն է, իսկ զուգընկերը հավելվածը աշխատեցնում է 10.200.0.7-ում։ Հանրային TCP 9443-ը քարտեզագրվում է զուգընկերի TCP 8443-ին՝
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1SNAT կանոնը համընկնում է թարգմանված բեքենդի և սկզբնական հանրային նպատակակետի հետ, ուստի նույն բեքենդ ծառայության մեկ այլ միացում մնում է այս քարտեզագրումից դուրս։ Այն նաև թաքցնում է այցելուի հասցեն զուգընկերից, և դա այն փոխանակությունն է, որը աղբյուրը պահպանող երթուղային վերադարձը դարձնում է առանձին նախագիծ։ iptables ընդլայնումների տեղեկատուն նկարագրում է երկու թիրախներն էլ և դրանց համապատասխանեցման ընտրանքները։
Փոխանցումը դեռ պետք է միացված լինի, և զտիչ շղթան պետք է թույլտվություն ունենա թարգմանված նպատակակետի ու պորտի, ինչպես նաև հաստատված պատասխանների համար։ FORWARD շղթան DNAT-ից հետո տեսնում է թարգմանված նպատակակետը, ուստի հանրային հասցեի դեմ գրված կանոնը չի համընկնում փոխանցված փաթեթի հետ։ Թույլտվությունը գրեք բեքենդի բազմակի դեմ, ոչ թե հանրայինի։
Զուգընկերը պետք է ընդունի ծառայության միացումը դարպասի թունելի հասցեից և պատասխանը հետ ուղարկի թունելով։ Նրա AllowedIPs-ը պետք է լիազորի այն աղբյուրը, որը նա իրականում ստանում է, և աղբյուրի թարգմանության դեպքում դա դարպասի թունելի հասցեն է, իսկ 0.0.0.0/0 լայն գրառումը յուրաքանչյուր զուգընկերի վրա այս նախագծի համար պարտադիր չէ։ Վերադարձի տրաֆիկը կտրում է այն զուգընկերը, ում ցանկը բաց է թողնում այդ հասցեն, կամ աղբյուրը պահպանող նախագիծը, որը փոխանցում է հենց այցելուի հասցեն, ուստի ստուգեք այն աղբյուրը, որը զուգընկերը իսկապես տեսնում է, ոչ թե ձեր կանոնի մեջ եղածը։
Դարպասի սեփական լսողներին դուրս պահեք կանոնից
Փոխարինեք պորտի համընկնումը կանոնով, որը ծածկում է բոլոր TCP և UDP նպատակակետերը, և դարպասի սեփական WireGuard սոքեթը կհայտնվի դրա ներսում։ Նպատակակետի թարգմանությունը տեղի է ունենում նախքան մեքենան կորոշի, որ փաթեթը տեղական է, ուստի UDP 51820-ը կարող է հայտնվել զուգընկերի մոտ, այլ ոչ թե այն գործընթացի մոտ, որը պահում է բոլոր զուգընկերային միացումները։ Կանոնը բեռնվում է հաջողությամբ, և թունելը մահանում է, ինչը դժվար ընթեռնելի ձախողում է զուգընկերի կողմից։
SSH-ը, մոնիտորինգի գործակալները և դարպասի վրա տեղակայված ցանկացած այլ ծառայություն ունեն նույն ենթարկվածությունը։ Կանոնը, որը փոխանցում է ամեն ինչ, չի տարբերում կառավարման հարթությունը հրապարակված հավելվածից, և փոփոխությունից հետո առաջին վերագործարկումն այն պահն է, երբ արգելափակումը դառնում է ակնհայտ։ Ամեն ինչ ընդգրկող կանոնը չի զգուշացնում այն ծառայության մասին, որը լուռ ստանձնում է։ Դուք դա բացահայտում եք, երբ հաջորդ միացումը ձախողվում է։
Եթե լայն փոխանցումն իսկապես անհրաժեշտ է, վերապահեք կառավարման պորտերը մինչև ամեն ինչ ընդգրկող կանոնը կամ օգտագործեք առանձին հանրային հասցե հրապարակման համար։ Երկրորդ տարբերակն ավելի մաքուր է, քանի որ կառավարման հասցեն պահում է իր քաղաքականությունը, բայց մատակարարը պետք է տրամադրի այդ հասցեն․ DNS գրառում ավելացնելը նրան չի հատկացնում։
Լայն TCP և UDP փոխանցումը նույնպես բոլոր արձանագրությունները չեն։ ICMP-ն, IPv6-ը, ուղու MTU հետադարձ կապը և VPN-ի արտաքին տրանսպորտը պետք է ունենան իրենց քաղաքականությունը, և TCP-ն ու UDP-ն ծածկող կանոնը այդ դեպքերը թողնում է լռելյայն շղթային։
Ընտրեք մոդելը նախքան կանոններ գրելը
Չորս ձև ծածկում են դարպասների հրապարակումների մեծ մասը, և ընտրությունը կախված է նրանից, թե քանի ծառայություն եք վարում և որքան կառավարման հարթության ռիսկ կարող եք հանդուրժել։ Ստորև բերված աղյուսակը դասավորում է դրանք ամենանեղից ամենալայնը։
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
Սկսեք նեղ մոդելից, նույնիսկ եթե հետագայում ավելի շատ ծառայություններ եք սպասում։ Այն ամենահեշտն է աուդիտի ենթարկվում, և նեղ կանոնների հավաքածուն վերափոխելը ստուգված ամեն ինչ ընդգրկող կանոնի ավելի պարզ է, քան պարզելը, թե որ լսողին է գրավել լայն կանոնը։ Ինչ մոդել էլ ընտրեք, կանոնները պահեք ֆայրվոլի տիրոջ մոտ։ iptables տողերը UFW-ի կամ nftables-ի կոնֆիգուրացիայի կողքին կիրառելը, որը նույնպես կառավարում է այդ շղթաները, ստեղծում է քաղաքականություն, որը փոխվում է՝ կախված բեռնման հերթականությունից։
Ապացուցեք և՛ հրապարակումը, և՛ կառավարման ուղին
Փորձարկեք լիազորված արտաքին հաճախորդից՝ օգտագործելով հաստատված հոսթի անունը և դրա համար վավեր վկայական։ Հաստատեք, թե որ բեքենդն է պատասխանել, ապա ստուգեք, որ չկապված հանրային պորտերը մնում են արգելված։ Անջատված վկայականի ստուգումը հաջող HTTPS թեստ չէ, և սխալ բեքենդին հասնող միացումն ավելի վատ է, քան ձախողվածը։
Դրանից հետո ստուգեք ինքը դարպասը՝ միացրեք WireGuard զուգընկեր, բացեք SSH նստաշրջան և հաստատեք, որ մոնիտորինգը դեռ հաշվետվություն է տալիս։ Հրապարակված ծառայությունը կարող է աշխատել, մինչ կառավարման հարթությունը կոտրված է, ուստի երկու ստուգումներն էլ պատկանում են նույն փոփոխության պատուհանին։ Վերագործարկեք մեկ անգամ՝ ապացուցելու, որ կանոնները կրկին կիրառվում են սպասվող հերթականությամբ, ապա հեռացրեք հրապարակումը և հաստատեք, որ հեռացումը իսկապես համապատասխանում է ավելացմանը։ Մեկնարկային շատ ավելացումներ՝ թերի մաքրմամբ, այն է, ինչը ժամանակավոր թեստը դարձնում է մշտական բացվածք։