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

Повезани чланци