Дали името на домаќинот на 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 записот едноставно го следи закупот. Ништо не мора да следи подвижна цел, бидејќи целта не се движи.

Надгледуван ажурирач е другиот легитимен модел и му треба сопственик.

Прикачете ја адресата или сами пуштете го ажурирачот

За мала LAN, резервација на 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 мора да знае како да ја достигне клиентската подмрежа, а нејзиниот ѕид на огнот мора да го дозволува сообраќајот на тунелот. Стандардната рута додадена за да го прикрие несовпаѓањето обично ја крие вистинската дупка и по една недела крши нешто друго.

Поврзани статии