Статикалык маршрутту шлюз атына багыттоо дарек өзгөргөндө сакталып калышы керек окшойт, бирок андай болбойт. Ат 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 кардардын ички тармагына кантип жетүүнү билиши керек, ал эми анын фаерволу туннелдин трафигине уруксат бериши керек. Шайкешсиздикти жашыруу үчүн кошулган демейки маршрут адатта чыныгы боштукту жашырат жана бир жумадан кийин башка нерсени бузат.

Тектеш макалалар