Pi шлюзінің хост атауы статикалық маршруттарды өз бетінше жаңарта ма?

Pi шлюзіңіз үшін DNS атауы орнатылған келесі секірісті ешқашан қайта жазбайды. Ядро нені сақтайтынын және маршрутты кім жаңартуы керектігін қараңыз.

Статикалық маршрутты шлюз атауына бағыттау мекенжай өзгерісінен аман өтуі керек сияқты көрінеді, бірақ олай болмайды. Атау 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 серверіндегі резервтеу ең арзан шешім. Динамикалық пулдан тыс мекенжай таңдаңыз, оны Pi-дің MAC мекенжайына байланыстырыңыз және келесі жалдау жаңартылғаннан кейін 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 клиенттің ішкі желісіне қалай жетуді білуі керек, ал оның фаерволы туннель трафигіне рұқсат беруі керек. Сәйкессіздікті жасыру үшін қосылған әдепкі маршрут әдетте нақты алшақтықты жасырады және бір аптадан кейін басқа нәрсені бұзады.

Қатысты мақалалар