Статик маршрутыг гарцын нэр рүү чиглүүлэх нь хаяг өөрчлөгдөхөд тэсвэрлэх ёстой мэт санагддаг ч тэсвэрлэдэггүй. Нэр нь 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 клиентийн дэд сүлжээнд хэрхэн хүрэхээ мэдэх ёстой, галт хана нь туннелийн трафикийг зөвшөөрөх ёстой. Зөрүүг далдлахаар нэмсэн анхдагч маршрут ихэвчлэн жинхэнэ цоорхойг нууж, долоо хоногийн дараа өөр зүйлийг эвддэг.

Холбоотой нийтлэлүүд