часть 4. ПРОБЛЕМА ШЛЮЗА ПО УМОЛЧАНИЮ

Thank you for reading this post, don't forget to subscribe!

Как хост может узнать, сле­ду­ет ли пытать­ся отпра­вить пакет хосту через сег­мент, к кото­ро­му он под­клю­чен, или отпра­вить пакет на марш­ру­ти­за­тор для даль­ней­шей обра­бот­ки? Если хост дол­жен отправ­лять паке­ты на марш­ру­ти­за­тор для даль­ней­шей обра­бот­ки, как он может узнать, на какой марш­ру­ти­за­тор (если их несколь­ко) отправ­лять тра­фик? Эти две про­бле­мы вме­сте состав­ля­ют про­бле­му шлю­за по умолчанию.

Для IPv4 про­бле­му доволь­но лег­ко решить, исполь­зуя пре­фикс и дли­ну пре­фик­са. Рису­нок ниже демон­стри­ру­ет нам это.

Реа­ли­за­ции IPv4 пред­по­ла­га­ют, что любой хост в пре­де­лах одной под­се­ти IPv4 дол­жен быть физи­че­ски под­клю­чен к одно­му про­во­ду. Как реа­ли­за­ция может опре­де­лить раз­ни­цу? Мас­ка под­се­ти - это еще одна фор­ма дли­ны пре­фик­са, кото­рая ука­зы­ва­ет, где закан­чи­ва­ет­ся сете­вой адрес и начи­на­ет­ся адрес хоста. В этом слу­чае пред­по­ло­жим, что дли­на пре­фик­са рав­на 24 битам, или сете­вой адрес равен /24. 24 ука­зы­ва­ет вам, сколь­ко битов зада­но в мас­ке под­се­ти: 24 bits = 11111111.11111111.11111111.0000000

Посколь­ку в IPv4 исполь­зу­ет­ся деся­тич­ная запись мас­ки, это так­же мож­но запи­сать как 255.255.255.0. Что­бы опре­де­лить, нахо­дит­ся ли C на том же про­во­де, что и A, A будет:

  1. Логи­че­ское умно­же­ние мас­ки под­се­ти с адре­сом локаль­но­го интерфейса
  2. Логи­че­ское умно­же­ние мас­ки под­се­ти с адре­сом назначения
  3. Срав­ни­те два резуль­та­та; если они сов­па­да­ют, целе­вой хост нахо­дит­ся на том же кана­ле свя­зи, что и локаль­ный интерфейс

На рисун­ке ниже это продемонстрировано.

На рисун­ке выше пока­за­но четы­ре IPv4-адре­са; пред­по­ло­жим, что A дол­жен отправ­лять паке­ты в C, D и E. Если A зна­ет, что дли­на пре­фик­са локаль­но­го сег­мен­та состав­ля­ет 24 бита либо с помо­щью руч­ной настрой­ки, либо с помо­щью DHCPv4, то он может про­сто посмот­реть на 24 наи­бо­лее зна­чи­мых бита каж­до­го адре­са, срав­нить его с 24 наи­бо­лее зна­чи­мы­ми бита­ми сво­е­го соб­ствен­но­го адре­са и опре­де­лить, нахо­дит­ся ли пункт назна­че­ния на сег­мен­те или нет. Два­дцать четы­ре бита IPv4-адре­са созда­ют хоро­ший раз­рыв меж­ду тре­тьей и чет­вер­той сек­ци­я­ми адре­са (каж­дая сек­ция IPv4-адре­са пред­став­ля­ет собой 8 бит адрес­но­го про­стран­ства, в общей слож­но­сти 32 бита адрес­но­го пространства).

Любые два адре­са с таки­ми же левы­ми тре­мя сек­ци­я­ми, что и у A, назы­ва­е­мые сете­вым адре­сом, нахо­дят­ся в одном сег­мен­те; любой адрес, кото­ро­го нет в сег­мен­те. В этом слу­чае сете­вой адрес для A и C сов­па­да­ет, поэто­му A будет счи­тать, что C нахо­дит­ся в одном сег­мен­те, и, сле­до­ва­тель­но, будет отправ­лять паке­ты C напря­мую, а не отправ­лять их на марш­ру­ти­за­тор. Для любо­го пунк­та назна­че­ния, кото­рый A счи­та­ет вне сег­мен­та, он будет отправ­лять паке­ты на IPv4-адрес конеч­но­го пунк­та назна­че­ния, но на MAC-адрес шлю­за по умол­ча­нию. Это озна­ча­ет, что марш­ру­ти­за­тор, высту­па­ю­щий в каче­стве шлю­за по умол­ча­нию, при­мет пакет и пере­клю­чит его на осно­ве IPv4-адре­са назна­че­ния. Как выби­ра­ет­ся шлюз по умол­ча­нию? Он либо настра­и­ва­ет­ся вруч­ную, либо вклю­ча­ет­ся в пара­метр DHCPv4.

А что насчет D? Посколь­ку сете­вые части адре­сов не сов­па­да­ют, A будет счи­тать, что D нахо­дит­ся вне сег­мен­та. В этом слу­чае A отпра­вит любой тра­фик для D на свой шлюз по умол­ча­нию, кото­рым явля­ет­ся B. Когда B полу­чит эти паке­ты, он пой­мет, что A и D дости­жи­мы через один и тот же интер­фейс (на осно­ве сво­ей таб­ли­цы марш­ру­ти­за­ции), поэто­му он будет отправ­лять ICMP-пере­на­прав­ле­ние на A, гово­ря ему, что нуж­но отправ­лять тра­фик на D напря­мую, а не через B.

IPv6 пред­став­ля­ет собой более слож­ный набор про­блем, кото­рые необ­хо­ди­мо решить при выбо­ре шлю­за по умол­ча­нию, пото­му что IPv6 пред­по­ла­га­ет, что одно устрой­ство может иметь мно­го адре­сов IPv6, назна­чен­ных кон­крет­но­му интер­фей­су. Рису­нок ниже демон­стри­ру­ет это.

На рисун­ке выше пред­по­ло­жим, что адми­ни­стра­тор сети настро­ил сле­ду­ю­щие политики:

  • Ни один хост не может под­клю­чать­ся к A, если у него нет адре­са в диа­па­зоне адре­сов 2001: db8: 3e8: 110 ::/64.
  • Ни один хост не может под­клю­чить­ся к D, если у него нет адре­са в диа­па­зоне адре­сов 2001: db8: 3e8: 112 ::/64.

При­ме­ча­ние: В реаль­ном мире вы нико­гда не постро­и­ли бы такую поли­ти­ку; это наду­ман­ная ситу­а­ция, что­бы про­ил­лю­стри­ро­вать про­бле­му, постав­лен­ную в сети мини­маль­но­го раз­ме­ра. Гораз­до более реаль­ной про­бле­мой тако­го же типа была бы одно­ад­рес­ная пере­ад­ре­са­ция обрат­но­го пути (uRPF).

Что­бы эти поли­ти­ки рабо­та­ли, адми­ни­стра­тор назна­чил 110::3 и 112::12 хосту C и 111::120 хосту F. Это может пока­зать­ся стран­ным, но совер­шен­но закон­но для одно­го сег­мен­та иметь несколь­ко под­се­тей IPv6, назна­чен­ных в IPv6; так­же совер­шен­но закон­но иметь одно устрой­ство с несколь­ки­ми адре­са­ми. На самом деле, в IPv6 суще­ству­ет мно­же­ство ситу­а­ций, когда одно­му устрой­ству может быть назна­чен диа­па­зон адресов.

Одна­ко с точ­ки зре­ния дли­ны пре­фик­са нет двух адре­сов, назна­чен­ных C или F, в одной под­се­ти. Из-за это­го IPv6 не пола­га­ет­ся на дли­ну пре­фик­са, что­бы опре­де­лить, что нахо­дит­ся в сег­мен­те, а что нет. Вме­сто это­го реа­ли­за­ции IPv6 ведут таб­ли­цу всех под­клю­чен­ных хостов, исполь­зуя запро­сы сосе­дей, что­бы опре­де­лить, что нахо­дит­ся в сег­мен­те, а что нет. Когда хост хочет отпра­вить тра­фик из локаль­но­го сег­мен­та, он отправ­ля­ет тра­фик на один из марш­ру­ти­за­то­ров, о кото­ром он узнал из объ­яв­ле­ний марш­ру­ти­за­то­ра. Если марш­ру­ти­за­тор полу­ча­ет пакет, к кото­ро­му, как он зна­ет, дру­гой марш­ру­ти­за­тор в сег­мен­те име­ет луч­ший марш­рут (посколь­ку у марш­ру­ти­за­то­ров есть таб­ли­цы марш­ру­ти­за­ции, кото­рые гово­рят им, какой путь выбрать к како­му-либо кон­крет­но­му месту назна­че­ния), марш­ру­ти­за­тор отпра­вит сооб­ще­ние пере­на­прав­ле­ния ICMPv6, сооб­ща­ю­щее хосту исполь­зо­вать какой-либо дру­гой марш­ру­ти­за­тор пер­во­го пере­хо­да для дости­же­ния пунк­та назначения.