Մեկ հանրային հոսթ VPN-ի և վեբի համար. ինչպես բաժանել դերերը

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

Այն, ինչ հաջորդում է, որոշման ընթացակարգ է, ոչ թե կառուցման թերթ։ Յուրաքանչյուր քայլ ավարտվում է ստուգմամբ, որն ապացուցում է, որ հենց նոր ավելացված դերը իսկապես մեկուսացված է։

Ընտրեք հասցեի տիրոջը պորտերից առաջ

Թունելի վերջնակետը և վեբ սերվերը կարող են կիսել միջուկը. մեկ հասցեի, պորտի և արձանագրության միաժամանակյա կիսումն է, որ ձախողվում է։ WireGuard-ը սովորաբար վերցնում է UDP 51820, OpenVPN վերցնում է UDP 1194 կամ TCP 443, իսկ վեբ սերվերը՝ TCP 443։ Ցավեցնող զույգը HTTPS-ի կողքին TCP 443-ի վրայով OpenVPN-ն է, որովհետև երկուսն էլ ուզում են նույն սոքեթը, և միջուկը տալիս է այն նրան, ով առաջինն է կապել։ Միայն առջևում գտնվող դեմուլտիպլեքսորը, ինչպիսին sslh-ն է կամ TLS-ին տեղյակ պրոքսին, թույլ է տալիս նրանց կիսել այդ պորտը, և այն ավելացնում է բաղադրիչ, որի խափանումը ճիշտ նման է firewall-ի խնդրի։

Նայեք տերերին նախքան որևէ բան փոխելը. ss -lntup տպում է յուրաքանչյուր լսող սոքեթի տեղական հասցեն, պորտը և գործընթացը։ Երկու տող, որոնք ցույց են տալիս 0.0.0.0:443, նշանակում են, որ երկրորդ ծառայությունը երբեք չի կապվել, որքան էլ ուրախ լիներ նրա init սկրիպտը։ Կամուրջը նույնպես տեղափոխում է տիրոջը։ Երբ eth0 միանում է br0-ին, IP-ն անցնում է br0-ին, և ամեն firewall կանոն, որը նշում է eth0-ը, դադարում է համընկնել, ուստի ծառայությունները կապեք կամրջի վրա և հաստատեք ip -br addr-ով։

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

Ուղղորդեք երկու LAN-երի միջև կամ NAT արեք մեկ կողմը

Երկու LAN, որոնք չեն տեսնում միմյանց, կարող են զանգահարել հանրային հոսթին, որը հետո փոխանցում է թունելների միջև։ Այդ ուղղորդված ձևավորմանը պետք է երեք բան՝ միացված փոխանցում, երթուղի դեպի յուրաքանչյուր հեռավոր նախածանց և փոխանցման քաղաքականություն, որը բաց է թողնում տրանզիտը։ sysctl -w net.ipv4.ip_forward=1 ծածկում է առաջինը, ip route add 10.20.0.0/24 dev wg1 երկրորդը, և nftables տող, ինչպիսին nft add rule inet filter forward iifname "wg0" oifname "wg1" accept երրորդը։

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

Ոչինչ այն փաստի մեջ, որ տուփը ծառայում է որպես ինտերնետ ելք նոութբուքի համար, չի խանգարում նույն տուփին ավարտել մուտքային թունելները։ Խանգարում են միայն համընկնող հասցեները, և դրա համար է, որ հասցեների պլանն է կարևոր փաստաթուղթը։

Փորձարկեք բաժանումը, երբ երկու դերերն անջատված են

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

Երեք հրաման այդ փորձարկումը դարձնում են շոշափելի։ curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ ապացուցում է, որ տեղական լսողը պատասխանում է առանց արտաքին DNS-ի, wg show հաճախորդի վրա ապացուցում է, որ ձեռքսեղմումը ավարտվել է, և tcpdump -ni any port 51820 հանգույցի վրա առանձնացնում է ուղղորդման խնդիրը բանալու խնդրից։ Ձեռքսեղմումը, որը երբեք չի հայտնվում գրավման մեջ, մահացել է հոսթից առաջ. մատակարարի firewall, սխալ հանրային հասցե կամ ճանապարհին NAT կանոն։

Կրկնեք հանումը փոխանցվող LAN-երի համար։ Մեկ զուգընկերոջ անջատված վիճակում հանգույցով անցնող ping-ը պետք է ձախողվի. նորից միացված վիճակում ping-ը պետք է վերականգնվի առանց կանոնին դիպչելու։ Ping-ը, որը վերականգնվում է միայն թունելը վերագործարկելուց հետո, մատնացույց է անում քաղաքականությանը, ոչ թե հասանելիությանը, և դա այլ ուղղում է։

Պահեք կանոնների հավաքածուն ընթեռնելի, երբ դերեր եք հանում։ nft list ruleset պետք է ցույց տա մեկ ընդունման կանոն յուրաքանչյուր ուղղության համար, որն իսկապես պետք է, և ամեն ինչ ընդունող փոխանցման շղթան բաժանում չէ, այլ աշխատող ցուցադրություն։

Միայն IPv6 մուտքի գծեր և IPv4 ծառայություններ

Որոշ մուտքի գծեր տալիս են միայն IPv6 հասանելիություն, և ծառայությունները դեռ պետք է հրապարակվեն IPv4-ի վրա։ Ինքը թունելը գնում է այն ընտանիքով, որը դեռ անցկացնում է երթևեկությունը, մինչդեռ հրապարակված ծառայությունը նստում է թունելի ներսի հասցեի վրա։ Սա շրջում է սովորական ենթադրությունը և հանգիստ կոտրում է մոնիտորինգը. IPv4 ուղու համար գրված firewall կանոնը կամ աշխատաժամանակի ստուգումը հիմա հսկում է ինտերֆեյս, որը ոչինչ չի կրում։

Փորձարկեք յուրաքանչյուր ընտանիք առանձին curl -4 և curl -6-ով, որովհետև մեկ հաջող հարցում ոչինչ չի ասում այն ուղու մասին, որը չեք փորձել։ Պորտի սեփականությունը չի փոխվում ընտանիքների միջև, բայց լսողը փոխվում է. ss -lntup թվարկում է IPv4 և IPv6 սոքեթները առանձին տողերով, և 0.0.0.0:443 չի ծածկում [::]:443-ը, եթե գործընթացը dual-stack սոքեթ չի խնդրել։

Ծառայությունը, որը պատասխանում է մեկ ընտանիքում և մերժում մյուսում, սովորաբար լսողի խնդիր է, ոչ թե ուղղորդման։ Նախքան ձևավորումը պատրաստ հայտարարելը, հաստատեք, որ յուրաքանչյուր դեր ունի իր հասցեն կամ պորտը, փոխանցումը միացված ու թույլատրված է, և յուրաքանչյուր դեր դեռ պատասխանում է, երբ մյուս երկուսը կանգնած են։