Meshnet, Docker и дозвола између њих

Две URL адресе могу изгледати исто из прегледача чвора, а значити сасвим различите ствари за заштитни зид. Једна показује на услугу која слуша на самом домаћину. Друга показује на адресу домаћина чији је порт објављен у мрежу контејнера, где корак превода предаје везу другом IP-у. У мрежи чвор-до-чвора која контролише приступ локалној мрежи дозволом за сваки чвор, та разлика је цео преглед.

Дозвола се односи на крајњу тачку домаћина, превод се односи на Docker, а пријава се односи на апликацију. Три одлуке, три места за поглед.

Пратите одредиште после објављивања

Узмите Linux Docker домаћин који објављује порт 80 контејнера на порту домаћина 8080. Чвор се повезује на мрежну адресу домаћина на 8080, домаћин прихвата везу и превод одредишта је преписује ка адреси моста контејнера, обично нешто попут 172.17.0.2 на порту 80.

Када правило прегледа тај ток, занимљиво одредиште је контејнер, а не домаћин. Политика која расуђује само о „услузи на овој машини“ расуђује о погрешном објекту. Захтев је слетео на домаћина, али се доставља негде другде.

Зато документација мреже наводи Docker контејнере међу ресурсима којима дозвола локалне мреже управља на Linux-у. Дозвола није синоним за обичан унос на листи дозвољених VPN-а и две контроле се не замењују. Једна одлучује да ли чвор уопште може да стигне до локалних ресурса; друга одлучује које одредишне тачке носи тунелска рута.

Одлучите колико локалног приступа дозвола даје

Давање приступа локалној мрежи чвору није одлука о једном контејнеру. Оно може изложити друге објављене услуге на истом домаћину и може стићи даље зависно од тога како домаћин прослеђује. Прегледајте стварни обим пре него што притиснете прекидач за једну контролну таблу.

Затим погледајте где Docker објављује порт. Објављивање на 0.0.0.0 ствара слушаоца на свакој адреси домаћина, што може додати обичан LAN унос поред мрежног. Ако је захтев само мрежа, вежите објављивање за одређену адресу или интерфејс који имате на уму, и третирајте шире везивање као одвојен налаз, а не као погодност.

Држите политику прослеђивања домаћина и сопствену аутентификацију апликације довољно уским за услугу. URL који изгледа приватно није контрола приступа, а контејнер који верује сваком извору на својој мостовној мрежи није заштићен чињеницом да је чвор мреже одобрен. Аутентификација апликације је трећа одлука и једина која зна ко је корисник. Дозвола на нивоу домаћина не може да пружи то знање.

Тестирајте дозволу, не само URL

Са одобреног чвора отворите тачну услугу и потврдите да ради. Затим покушајте одредиште које треба да остане одбијено и потврдите да не ради. Тестирање само срећног пута вам каже да је дозвола дата; не каже да је граница тамо где мислите.

Одвојено упоредите услугу која је својствена домаћину. Ако база података слуша на домаћину, а контролна табла ради у контејнеру, оне иду различитим путевима кроз исту дозволу и можда их политика прослеђивања домаћина не контролише исто. Запишите шта је шта пре него што напишете белешку о прегледу.

Не празните Docker табеле или правила клијента мреже да бисте „ресетовали“ приступ. Оба производа инсталирају своју интеграцију политика, а њено брисање ствара домаћина који изгледа да ради док заобилази контроле које је од вас тражено да оцените. Ако правило изгледа погрешно, прочитајте га и промените баш то правило. Ако не можете да објасните шта правило ради, то је налаз, а не разлог да га избришете.

Напишите налаз терминима самог система

Важна је разлика коју производ заиста спроводи, а не она у шаблону прегледа: дозвола да се стигне до крајње тачке домаћина, дозвола да се стигне до рутираних приватних ресурса и дозвола да се користи апликација. Објављивање порта оставља те три одлуке тачно тамо где су биле, а прегледач који их третира као једну одобриће погрешан обим.

Наведите адресу домаћина, објављени порт, одредиште контејнера и дозволу чвора у истој реченици. Ту реченицу може да провери неко други и то је чини налазом, а не мишљењем.