Nebula փարոսի զտիչները ընդդեմ հրապատի. ինչ է արգելափակում յուրաքանչյուրը

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

Հետևեք մեկ կապին չորս փուլով՝ հայտարարված տեղական հասցեն, դիտարկվող հեռավոր վերջնակետը, ձեռքսեղմումը և overlay-ի երթևեկությունը։ Յուրաքանչյուր փուլ ունի իր կարգավորումը և իր խափանման ստորագրությունը։

Սկսեք այն տեղական հասցեից, որը հայտարարում է հանգույցը

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

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

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

Այնուհետև դիտեք հեռավոր վերջնակետի ընտրությունը

remote_allow_list զտում է այն հասցեները, որոնք այս հոսթը կդիտարկի հեռավոր գործընկերոջ համար ձեռքսեղմման ընթացքում։ Այն վերաբերում է ստորին շերտի հասցեին, ոչ թե overlay-ի հասցեին, որը գործընկերը կօգտագործի թունելը բարձրացնելուց հետո։

Մասնավոր միջակայքը կարող է լիովին օգտագործելի լինել ընդհանուր գրասենյակային ցանցում և անիմաստ լինել, երբ երկու հոսթերը գտնվում են անկապ ցանցերում, որոնք երկուսն էլ օգտագործում են 10.0.0.0/8։ Զտիչը թույլ է տալիս նախընտրել երթուղավորելի ուղին և անտեսել պատահականությունը։

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

Հայտարարող կողմի ինտերֆեյսի անվան զտիչը կարող է հեռացնել վերջնակետը նախքան ստացող կողմը կտեսնի այն։ Ստուգեք երկու հանգույցներն էլ, երբ ձախողվում է միայն մեկ ուղղությունը։

Ձեռքսեղմումից հետո գործում են overlay-ի մուտքի կանոնները

Nebula-ի հրապատի կանոնները գործում են overlay-ի ներսում՝ թունելի հաստատումից հետո։ Նրանք համապատասխանեցնում են հոսթեր, խմբեր, պորտեր և արձանագրություններ և որոշում են, թե արդյոք փաթեթը կարող է մուտք գործել տեղական հոսթ կամ դուրս գալ դրանից։ Նրանք վերջնակետ չեն ընտրում ստորին ցանցում։

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

Կարդացեք խափանումը ճիշտ շերտում։ Ձեռքսեղմումը, որը երբեք չի ավարտվում, մատնանշում է հայտնաբերումը, վերջնակետերի զտումը կամ ցանցային ուղին։ Ավարտված ձեռքսեղմումը, որին հաջորդում է մերժված կամ գցված ծառայության կապ, մատնանշում է overlay-ի հրապատը կամ հավելվածը։

Կարդացեք լռելյայնը, երբ խառնում եք թույլատրումն ու արգելումը

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

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

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

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

Օգտագործեք relay, երբ ուղիղ վերջնակետ հասանելի չէ

Եթե յուրաքանչյուր թեկնածու վերջնակետ զտված է կամ անհասանելի, պատասխանը ավելի լայն թույլատրելի ցանկ չէ, որը նորից ընդունում է այն հասցեները, որոնց չեք վստահում։ Nebula-ի relay կարգավորումն այլընտրանքային գործընկերային ուղի է ապահովում, երբ ուղիղ կապը հնարավոր չէ։

Relay-ը լուծում է տրանսպորտը և հայտնաբերումը, ոչ թե լիազորումը, և այն չի լայնացնում հրապատը։ Overlay-ի հրապատը դեռ որոշում է, թե որ ծառայությունները կարող են օգտագործվել, և relay-ը փարոսի զտումը չի դարձնում մուտքի կառավարման մեխանիզմ։

Ստուգեք relay-ի ուղին անջատված ուղիղ վերջնակետերով և հաստատեք, որ նախատեսված ծառայությունը դեռ աշխատում է, իսկ չնախատեսվածը՝ ոչ։ Այդ մեկ թեստը բաժանում է տրանսպորտի ուղղումը քաղաքականության փոփոխությունից և պահում է երկու շերտերն ազնիվ։