Обновява ли името на хоста на Pi шлюз статичните маршрути самостоятелно?

DNS име за вашия Pi шлюз никога не пренаписва инсталирания следващ хоп. Вижте какво пази ядрото и кой трябва да обнови маршрута.

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

DNS отговорът и маршрутът са различни обекти

Да кажем, че вашият Pi отговаря на vpn-gw.lan и препраща 10.44.0.0/16 към тунел. Клиентите в 192.168.30.0/24 го достигат чрез статичен маршрут. Когато адресът на Pi се премести от 192.168.30.4 на 192.168.30.11, записът го последва в рамките на своя TTL, а маршрутите — не.

Двете гледни точки се разминават по начин, който лесно се пропуска, защото и двете изглеждат правдоподобни, когато ги заявите поотделно:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

Само първият ред решава накъде отиват пакетите. Вторият ред отговаря на въпрос, който ядрото никога не е задавало. Запис с няколко A записа също не се превръща в политика за превключване при отказ, тъй като всеки адрес все още трябва да бъде работещ следващ хоп в този сегмент.

Какво остава в таблицата след излизане от командата

Маршрутът в Linux записва две неща, които имат значение тук: следващия хоп като адрес на протокол и изходния интерфейс като номер на индекс. атрибутите на маршрута rtnetlink назовават това първо поле RTA_GATEWAY и то съдържа байтове. След като записът е на място, към него не е прикачен TTL и никакво фоново търсене не го обновява.

Ето защо ip route add 10.44.0.0/16 via vpn-gw.lan може да изглежда, че работи. Инструментът разрешава името, докато командата работи, записва получения адрес и забравя името напълно. Изпълнете ip route show 10.44.0.0/16 след това и ще получите обратно буквален адрес.

Това поведение си струва да се знае, преди да обвините тунела.

Инструменти, които разрешават име вместо вас, и кога

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

Управляваните среди обикновено разделят работата. DHCP резервация или статичен лийз държи Pi на един адрес, а DNS записът просто следва лийза. Нищо не трябва да следи движеща се цел, защото целта не се движи.

Наблюдаваният обновител е другият законен модел и той има нужда от собственик.

Заковайте адреса или пуснете обновителя сами

За малка локална мрежа резервация на DHCP сървъра е най-евтиното решение. Изберете адрес извън динамичния пул, свържете го с MAC адреса на Pi и го потвърдете с ip -4 addr show dev eth0 след следващото подновяване на лийза. След това насочете следващия хоп на клиентите към този адрес веднъж. Сега имате стабилен шлюз и запис, който го описва, а това е редът, в който връзката всъщност работи.

Ако Pi наистина трябва да се премести, дръжте поправката на маршрута на едно място, вместо да редактирате ръчно всеки клиент. Кратък скрипт, който разрешава, сравнява и заменя, е достатъчен, за да направи стъпката повторяема:

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

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

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

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