Ինչու աղբյուր-պորտի կանոնը կոտրում է ձեր SSH ուղիներից մեկը

Երկու կառավարման մուտք մեկ հոսթի վրա, մեկ ծառայության պորտ և քաղաքականության կանոն, որը պետք է օգներ երկուսին էլ։ Կանոնը համընկնում է աղբյուր-պորտ 22-ի հետ, որոնումն ուղարկում է աղյուսակ, որը գիտի միայն WAN-ի լռելյայնը, և VPN մուտքը դադարում է պատասխանել նոր մուտքերին, մինչ ուղղակի մուտքը շարունակում է աշխատել։ Այս ամենում ոչ մի խորհրդավոր բան չկա, երբ ընտրիչը ճիշտ կարդացվի։ Աղբյուր-պորտը նույնացնում է ծառայությունը, ոչ այն ուղին, որով եկել է կապը։

Երկու մուտք, մեկ ծառայության պորտ

Հոսթն ունի LAN-ի կողմի հասցե և VPN հասցե, և sshd-ը լսում է երկուսի վրա։ Այդ պատճառով ուղղակի նստաշրջանը և թունելային նստաշրջանը կիսում են ծառայության պորտը և տարբերվում են միայն նրանով, թե որ տեղական հասցեն է ընդունում կապը։

Այդ տարբերությունը բավական է պատասխանի ուղին ընտրելու համար, և հենց այն տարբերությունն է, որը պորտի վրա հիմնված կանոնը դեն է նետում։ Երկու նստաշրջաններն էլ ստեղծում են պատասխաններ, որոնց աղբյուր-պորտը 22 է, ուստի այդ պորտին համընկնող կանոնը չի կարող տարանջատել դրանք։ Այն երկու որոնումներն էլ ուղարկում է նույն աղյուսակ, և դրանցից մեկը ստանում է պատասխան, որը չի համապատասխանում։ Ուղղումը այն հատկանիշին համընկնելն է, որն իրոք տարբերվում է։

Յուրաքանչյուր մուտքի սեփական պորտ տալը նույնպես կաշխատի, և դա որպես պահանջ դիտարկելը դիզայնի ընտրություն է, ոչ թե SSH-ի հատկություն։

Կարդացեք կանոնը, ապա՝ աղյուսակը

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

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

ip -4 rule show
ip route show table 100
ip route show table main

Այս երկու ելքերը միասին բացատրում են արդյունքը՝ դրանցից յուրաքանչյուրը միայնակ հրավիրում է սխալ եզրակացության։

Սահմանափակեք կանոնը նախատեսված հոսքով

Երկու մուտքերը բաժանող հատկանիշը տեղական աղբյուրի հասցեն է։ Այդ հասցեին համընկնող կանոնը միայն թունելային նստաշրջաններն է ուղարկում մասնավոր աղյուսակ, իսկ ուղղակի նստաշրջանները թողնում է հիմնական աղյուսակում։

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Եթե երկու մուտքերը թարգմանվեն մեկ տեղական հասցեի, այդ տարբերությունը վերանում է, և դիզայնին փոխարենը պետք է կապից տեղյակ վիճակ։

Առանձին պահեք լսողը, թույլտվությունը և պատասխանի ընտրությունը

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

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

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

Ապացուցեք նոր նստաշրջանով, ոչ հինով

Հաստատված տերմինալը ոչինչ չի ապացուցում, քանի որ այն ընդունվել է փոփոխությունից առաջ։ Բացեք նոր նստաշրջան յուրաքանչյուր նախատեսված մուտքով։

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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