Възможни arp проблеми при едновременно използване на БТК ADSL и LAN доставчици

Този документ описва един доста неприятен arp проблем, който може (макар и много рядко) да се случи при едновременното използване на БТК ADSL и LAN доставчик през общ маршрутизатор. Подобно резервиране на интернет връзката през два доставчика е много популярно за малки офисни мрежи в офиси на български фирми (особено в София). Надявам се, че решението по-долу ще бъде полезно както на персонала по поддръжката на услугата БТК ADSL, така и на техническия персонал на LAN доставчиците. Описаното решение не засяга случаите, в които LAN доставчикът предоставя на клиента достъп до Интернет чрез протокол PPPoE с използване на публично адресно пространство (ако разбира се клиента не добавя адрес за частно използване върху етернет интерфейс с цел участие в локална мрежа за обмент на информация). То засяга само случаите, в който LAN доставчикът използва частно IP адресно пространство и маршрутизаторът му се намира в адресния сегмент 192.168.0.0.

Обикновено абонатите на ADSL улугата на БТК, използват Linux маршрутизатори, непосредствено свързани с модема чрез етернет кабел. В този случай ADSL модема и Linux маршрутизатора на клиента използват адреси от IP сегмента 192.168.0.0/24. Най-често върху ADSL модема се поставя адреса 192.168.0.1/24, а върху етернет интерфейса на клиентския Linux маршрутизатор се намира адрес 192.168.0.2/24. Това е най-често използваното разположение на адресите в сегмента, защото при такава настройка БТК реализират DNAT схемата за клиента (пренасочват пакетите, които идват към публичния адрес, към адреса за частно ползване на клиента 192.168.0.2/24).

Ако клиентът на услугата БТК ADSL реши да използва и връзка към LAN доставчик чрез включване към същия Linux маршрутизатор, на който е свързан ADSL модема, то може да има проблеми ако LAN доставчикът използва адресно пространство за частно ползване 192.168.0.0/24. Такова използване е проблемно, защото при него се получава така, че на два етернет интерфейса на една и съща машина (Linux маршрутизатора на клиента), се използва едно и също IP адресно пространство (в случая 192.168.0.0/24). Това води до двусмислие и подобна схема няма как правилно да работи. В този случай LAN доставчика решава най-често проблема като включва клиента в друго IP адресно пространство за да избегне дублирането. Най-често той прави това като в един и същи етернет сегмент използва два IP адресни сегмента, примерно 192.168.0.0/24 и 10.100.0.0/24 без да ги разделя физически (поради финансови и технически причини не се прави физическо разделяне в съответната LAN мрежа).

Подобно смело решение на LAN доставчика, в описания по-горе случай, може да доведе до много големи проблеми, при които всички негови клиенти, използващи адреси от IP сегмента 192.168.0.0/24, да изпитат затруднения при достъпването на някоя критична за функционирането на интенет свързаността услуга, която се намира на адрес 192.168.0.2, който пък от своя страна се намира на хост в локалната мрежа, различен от този на клиента. Защо това може да се случи? Едната причина е в използването на един физически етернет сегмент от два IP адресни сегмента. Втората (свързана с първата), се състои в това, че Linux маршрутизатора, при arp who-has запитване, може да даде отговор за наличие на IP адрес, който е асоцииран към произволен негов мрежови интерфейс, който не е физически свързан с мрежата на LAN доставчика.

Ето и конкретен пример. Върху Linux маршрутизатора има дефинирани следните интерфейси:

eth0 Link encap:Ethernet HWaddr 00:08:02:0B:99:FC
   inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
   inet6 addr: fe80::68f2:97ff:fe13:8534/64 Scope:Link
   UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b) TX bytes:70 (70.0 b)

eth1 Link encap:Ethernet HWaddr 00:08:02:0B:99:F1
   inet addr:10.100.0.253 Bcast:10.100.0.255 Mask:255.255.255.0
   inet6 addr: fe80::2e0:4dff:fe01:f8e8/64 Scope:Link
   UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b) TX bytes:70 (70.0 b)

Нека да си представим какво ще се случи в момента, в който хост от мрежата на LAN доставчика, член на IP сегмента 192.168.0.0/24 (примерно 192.168.0.20), реши да извърши arp запитване с цел намиране на хоста в локалната мрежа, който има IP адрес 192.168.0.2. Ще се окаже така, че два хоста, включени към физическия сегмент, ще имат върху себе си един и същи IP адрес. Това ще довете до колизия и липса на достъп до адреса.

Какво е необходимо да се направи, за да не се появява този проблем? Отговорът на този въпрос се крие в настройките на ядрото върху Linux маршрутизатора на клиента. Трябва да се извърши такава настройка, че при получаване на arp заявка who-has на даден локален интерфейс, да не се удовлетворява нейно съвпадение относно адреси, които се намират на интерфейси, физически несвързани със сегмента, от който идва arp who-has заявката. Ако се погледне примера по-горе, това означава, че ако хост от мрежата на LAN доставчика, който използва IP адрес от пространството 192.168.0.0/24 подаде arp who-has с цел да получи MAC адреса, на който се намира адреса 192.168.0.2, то не бива да се изпълнява тази заявка относно всички интерфейси на системата на Linux маршрутизатора, а само относно интерфейса eth1 (който физически е в сегмента на LAN доставчика, в който се намира IP адресния сегмент 192.168.0.0/24).

За да се извърши това е необходимо да се извърши следното указване във файла /etc/sysctl.conf:

net.ipv4.conf.all.arp_ignore = 1

Това указване е доста силно и може да се конкретизира само спрямо даден интерфейс (например спрямо eth1 от горния пример):

net.ipv4.conf.eth1.arp_ignore = 1

След като тази настройка бъде извършена, то остава да се въведе в действие чрез изпълнение на командния ред:

# sysctl -p

От тук нататък проблеми от естеството на описания по-горе няма да има.