VPN անվանատարածքի ներսում գտնվող հավելվածն անհասանելի է LAN-ից
Ցանցային անվանատարածքը մեկ ծրագրին տալիս է իր թունելն ու իր loopback-ը։ Հրապարակեք միայն նրա պորտը socat ցատկով կամ veth զույգով՝ հոսթի փոխարեն։
Ձեր ծառայությունը աշխատում է մեքենայի վրա, թունելը բարձրացված է, և այնուամենայնիվ ձեր սեղանի բրաուզերը դեռ պատասխանի է սպասում։ Ոչինչ կոտրված չէ սովորական իմաստով․ հավելվածը լսում է ցանցային անվանատարածքի ներսում, և այդ կույտն անտեսանելի է LAN-ի համար։ Նրա loopback-ը պատկանում է անվանատարածքին, ուստի մեկ այլ մեքենայի հաճախորդը չունի հասցե, որը հասնում է պորտին։ Մեկ դիտավորյալ ցատկ, կամ մեկ veth զույգ, ուղղում է դա՝ չշարժելով հոսթի մնացած մասը։
Ինչու ոչինչ չի պատասխանում LAN հասցեին
Անվանատարածքը ամբողջական ցանցային կույտ է․ ինտերֆեյսներ, երթուղիներ, firewall-ի կանոններ և մասնավոր loopback։ ip netns exec-ի միջոցով գործարկված պրոցեսը տեսնում է միայն այդ կույտը և ոչ այլ բան, ուստի այն հասցեն, որին այն կապվում է, լուծվում է միայն անվանատարածքի ներսում։ Հոսթի սեփական 127.0.0.1-ը բոլորովին այլ loopback է։
Այդ պատճառով հոսթի վրա curl-ը ձախողվում է, մինչդեռ անվանատարածքի ներսում նույն հրամանը հաջողվում է։ Հավելվածը առողջ է․ հասցեն պարզապես գոյություն չունի հոսթի կույտում։
Հրապարակեք մեկ պորտ socat ցատկով
socat-ը կամրջում է երկու կույտերը օգտատիրոջ տարածքում, ինչը բավական է, երբ պետք է անցնի մեկ TCP պորտ։ Հոսթի կողմը լսում է LAN-ում և յուրաքանչյուր ընդունված միացման համար անվանատարածքի ներսում գործարկում է երկրորդ socat, որը միանում է հավելվածի loopback-ին։ Ներքին պրոցեսը հասնում է հավելվածին ճիշտ այնպես, ինչպես կաներ տեղական հաճախորդը։ Անվանատարածքի երթուղայնության մեջ ոչինչ չի փոխվում, ուստի հավելվածը շարունակում է թունելն օգտագործել որպես իր միակ ելք։
socat TCP-LISTEN:9100,reuseaddr,fork EXEC:'ip netns exec vpn socat STDIO tcp-connect:127.0.0.1:9100',nofork
Արտաքին պրոցեսին անհրաժեշտ է root կամ անվանատարածք մտնելու հնարավորություն։ Եթե VPN-ը ընկնի, հավելվածը կկորցնի իր ուղին, և հրապարակված պորտը կձախողվի փակ վիճակում, ինչը հենց այն վարքն է, որ ուզում եք բանտից։
Օգտագործեք veth զույգ, երբ անցնում է մեկից ավելի պորտ
veth զույգը ճիշտ պատասխանն է, երբ պետք է անցնեն մի քանի պորտ կամ արձանագրություն, կամ երբ այլ հոսթեր պետք է միացումներ սկսեն։ Մի ծայրը մնում է հոսթում, մյուսը տեղափոխվում է անվանատարածք, և փոքր /30-ը երկու կողմերին տալիս է կայուն հասցե։ Այնուհետև հոսթի երթուղին ուղարկում է անվանատարածքի հասցեն զույգի վրայով։
ip link add veth0 type veth peer name veth1
ip link set veth1 netns vpn
ip addr add 10.77.0.1/30 dev veth0
ip link set veth0 up
ip netns exec vpn ip addr add 10.77.0.2/30 dev veth1
ip netns exec vpn ip link set veth1 up
Չավելացնեք լռելյայն երթուղի հոսթի միջով, եթե չեք մտադիր կոտրել բանտը։ Թունելը պետք է մնա ելքը, ուստի զույգի վրայով հասանելի է միայն հրապարակված ծառայության հասցեն։ Տվեք անվանատարածքին նաև իր սեփական resolver ֆայլը, որովհետև ip netns exec-ը կարդում է /etc/netns/vpn/resolv.conf-ը, և առանց դրա բանտի ներսում անունների լուծումը դատարկ է։
Փորձարկեք այլ մեքենայից, ոչ թե հոսթից
Գործարկեք թեստը երկրորդ մեքենայից, որովհետև հոսթը կարող է հասնել տեղական լսողին ուղիներով, որոնք ոչինչ չեն ասում LAN-ի մասին։ Նախ ստուգեք, թե ինչին է հավելվածն իրականում կապվել անվանատարածքի ներսում, ապա դրսից միացեք հրապարակված հասցեին։ Այնտեղ բոլոր հասցեներին կապվելը չի լայնացնում բանտը, որովհետև wildcard-ը դեռ պատկանում է անվանատարածքին, և LAN-ը չի կարող տեսնել այն։
ip netns exec vpn ss -lntp
Եթե հոսթից միացումը աշխատում է, իսկ LAN-իցը՝ ոչ, բացակայող մասը ցատկն է կամ երթուղին, ոչ թե կապման հասցեն։ Սկսեք OpenVPN-ը անվանատարածքի ներսում՝ փոխարենը այնտեղ տեղափոխելու կենդանի tun սարք, քանի որ ինտերֆեյսը տեղափոխելը անջատում է այն և կարող է ջնջել երթուղիներ, որոնք հետո դրսից չեք կարողանա վերանորոգել։ Վերականգնման հրամանները պահեք վահանակում, ոչ թե բանտի ներսում։