Работна станция в западната локална мрежа отваря браузър, въвежда адреса на приложение в източната локална мрежа и чака, докато не изтече времето за изчакване. Всеки екран на NetBird казва, че партньорите са свързани, което е вярно, но не по същество: да си в една овърлей мрежа не е същото като двете локални подмрежи в една мрежа. Разходката по-долу започва от тази работна станция и завършва със заявка, която дизайнът отказва нарочно, и всяка спирка е нещо, което се чете от устройство, а не се предполага. Очаквайте липсващото парче да е маршрут или политика, не овърлей.

Прочетете отказа първо от работната станция

Преди да отворите конзолата за управление, установете какво всъщност изпраща работната станция. Нейната собствена таблица за маршрутизиране решава дали пакетът отива към шлюза на сайта, към локален интерфейс или никъде, и това решение се вижда без никакви овърлей инструменти. Машина без маршрут за далечния префикс ще се провали, колкото и здрав да изглежда списъкът с партньори. Обхватът на овърлея и собственият префикс на сайта са различни адресни пространства, а регистрацията е настроила само едно от тях.

След това отделете разрешаването на имена от достъпността, защото браузърът съобщава и двете като едно и също изтичане на времето. Повторете заявката по адрес от машина с клиент NetBird, а после от обикновена работна станция без него. Ако регистрираната машина успее, а обикновената се провали, пропускът е в локалното маршрутизиране; ако и двете се провалят, продължете да четете, преди да промените маршрут.

Изберете един маршрутизиращ партньор за сайт

Маршрутизиращият партньор е хост, който представлява своята локална мрежа в овърлея, затова изберете Linux машина със стабилна достъпност до подмрежата, а не нечий настолен компютър. Регистрирайте я по нормалния ред и я поставете в група, наречена според ролята, защото мрежовият ресурс и политиката ще се позовават и двете на тази група. Един представител за сайт остава разбираем; тълпа от доброволци, обявяващи същия префикс, превръща всеки следващ въпрос в сесия по отстраняване на грешки. Адресът на партньора в локалния сегмент е толкова важен, колкото идентичността му в овърлея, защото този адрес става следващият хоп, който се казва на всяко обикновено устройство.

Запишете плана, преди да пипате конзолата, защото имената и префиксите са мястото, където тези дизайни се разминават: префикс, шлюз, адрес на партньора и група, за всеки сайт. Западът е 10.52.0.0/24, обслужван от 10.52.0.5, а изтокът е 10.63.0.0/24, обслужван от 10.63.0.5; двете групи са west-routers и east-routers и нито един префикс не бива да се припокрива с другия, с обхвата на овърлея или с друга маршрутизирана дестинация.

Създайте ресурса, оставете маскирането включено

В разположеното табло създайте един мрежов ресурс за сайт и прикачете към него групата на маршрутизиращия партньор за този сайт. Ресурсът е префиксът, а групата е хостът, който отговаря за него, и двете трябва да съществуват, преди нещо да бъде обявено. Потвърдете, че разположената самостоятелно хоствана версия изобщо има работния поток „Мрежи“, защото по-стар интерфейс с подобно назован обект за маршрут е друга функция.

Оставете маскирането включено. Ръководството на NetBird за връзка между сайтове го изисква при тази подредба, а изключването му, за да остане всеки оригинален адрес видим, не е същият дизайн с един хоп по-малко; то променя какво виждат проверките на източника и политиките на овърлея. Последствието заслужава да се каже направо: получаващата услуга записва като източник маршрутизиращия партньор, не отделната работна станция. Ако списъкът с разрешени или одитът на тази услуга очаква адреси на работни станции, или очакването се променя, или идентичността трябва да се наложи на границата на сайта преди превода.

Овластете инициаторите, не префиксите

Маршрутът прави адреса достъпен, а политиката решава кой може да го използва; двете са отделни обекти с отделни собственици. Напишете политиката от натоварването назад: коя група инициира, кой ресурс е целта и коя TCP услуга е нужна. Мрежа, която обявява двата префикса на всеки регистриран партньор, е създала достъпност и не е решила нищо.

После прочетете какво още вече е разрешено, защото тясно ново правило не отменя широко старо, което стои над него. Когато изтокът също трябва да започва връзки към запада, напишете тази посока като отделна политика; върнатият трафик за сесия, отворена от запада, е друг въпрос от разрешаването на нови сесии на изток. Ако само някои западни работни станции трябва да достигат източното приложение, изберете ги на границата на сайта преди превода и запазете собствената автентикация на приложението. Маршрутизиращият партньор носи трафика на локалната мрежа като целия сайт, а не като идентичност на отделен потребител в овърлея, затова отчитането по потребители трябва да идва от другаде.

Научете всеки шлюз на следващия хоп, после изпробвайте отказ

Обикновените устройства никога не виждат овърлея, затова собственият им шлюз се нуждае от статичен маршрут, който насочва далечния префикс към адреса на партньора в локалната мрежа. Тази стъпка се пропуска, защото всичко видимо в NetBird вече работи, докато обикновените работни станции още изтичат по време. Шлюзът запазва маршрута си по подразбиране както беше; този префикс е допълнение, не замяна.

Двете описания на маршрути принадлежат на конфигурацията на шлюза на всеки сайт, не на презапис на хоста. И двете са обикновени статични маршрути и нито едно не докосва маршрута по подразбиране:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Изпробвайте с приложението, което проектът наистина изисква, от обикновена работна станция, и запишете три неща: следващия хоп, избран от страната на изпращача, политиката, която е съвпаднала, и адреса на източника, който услугата е записала. Изпробвайте и отказ, защото дизайн, който никога не е отказал нищо, има неизвестни ръбове, и отказът е единственото доказателство, че политиката, а не маршрутизирането върши работата. Когато изтокът също трябва да инициира, започнете нова връзка от тази страна, вместо да предполагате, че втората посока следва. Планирайте и рестартирането, надграждането и замяната на маршрутизиращия партньор, защото един хост стана зависимост за сайта.

TestA pass looks likeA failure points at
Ordinary workstation opens the east applicationNext hop on west is the routing peerMissing static route on the west gateway
A source outside policy is refusedNo session in the service logPolicy too broad, or a route bypasses it
East starts a connection, if requiredA fresh reverse session succeedsNo policy for the reverse direction

Частните имена се нуждаят от собствен дизайн на резолвер, защото достъпността не създава DNS записи, а работещ IP път със счупено име се чете точно като счупен път. Ако маршрутизиращият партньор работи в облачна мрежа, прегледайте и правилата за препращане и защитната стена на доставчика, защото регистрацията не ги отменя. Дръжте наблюденията от теста до плана, защото следващият човек, който ще отстранява това, ще иска съвпадналата политика и записания адрес на източника, а не описание на топологията.

Подобни статии