Чаму рэзерваванне DHCP — не статычны IP для вашага VPN-сервера

Я перанёс хатні VPN-бокс з Wi-Fi на Ethernet, і яго «пастаянны» адрас змяніўся ў той жа вечар. На роўтары нічога не было зламана. Рэзерваванне супадала з бесправодным адаптарам, а гэтага адаптара ў шляху ўжо не было.

У гэтай жа памылковай уяўленні ёсць другая палова. Выпраўленне адрасу LAN нічога не робіць для адрасу, да якога падключаюцца вашыя сябры, і не мае ніякага дачынення да прыватнага пула, які VPN выдае кліентам. Тры адрасы, тры асобныя рэжымы адмовы, і толькі адзін з іх — справа рэзервавання.

Рэзерваванне супадае з кліентам, а не з прыладай

У DHCPv4 рэзерваванне прывязана да апаратнага адрасу кліента; у DHCPv6 — да DUID, які кліент павінен захоўваць. Поле hostname — гэта этыкетка для людзей. Роўтар фактычна параўноўвае ідэнтыфікатар, які прыходзіць у запыце.

Чытайце запіс як умову: калі гэты ідэнтыфікатар просіць, дайце яму гэты адрас. Прадаўжэнні захоўваюць тую ж арэнду, пакуль супадзенне трымаецца, а перазапуск проста пытае зноў. Калі ідэнтыфікатар змяняецца, запыт прапускае рэзерваванне, і кліент бярэ тое, што прапануе дынамічны пул. Ніякай памылкі, ніякага папярэджання, проста іншы адрас.

OpenWrt паказвае форму ясна. Адзін блок config host у /etc/config/dhcp звязвае імя, MAC і адрас разам, а дакументацыя пра статычныя арэнды тлумачыць, як гэты запіс узаемадзейнічае з пулам. Іншыя роўтары хаваюць тыя ж тры палі за рознымі этыкеткамі.

Дзе супадзенне ціха абрываецца

Замена абсталявання — звычайная справа. Змяніце сеткавую карту або перанясіце машыну паміж Ethernet і Wi-Fi, і адрас, які бачыць роўтар, змяняецца разам з ёй. Старое рэзерваванне застаецца ў спісе і выглядае правільным.

Пераўстаноўка — другі выпадак, і яна балюча ўдарае па IPv6. Свежая ўстаноўка можа стварыць новы DUID, пакуль старая арэнда IPv4 яшчэ дзейная, таму адрас v4 жыве нейкі час, а запіс v6 перастае прымяняцца без бачнага рэдагавання.

Трэці — замацаваны ідэнтыфікатар кліента. Некаторыя кліенты DHCP дазваляюць задаць радок ідэнтыфікатара замест выкарыстання MAC. Калі абнаўленне або перазапіс канфігурацыі скідвае гэтую наладу, супадзенне знікае, нават калі машына не перамяшчалася.

Чацвёрты — дубліраванне: састарэлы блок і новы блок для таго ж хоста. Сервер адказвае тым правілам, якое супадае, часта адрасам пула, якога вы хацелі пазбегнуць. Выдаліце састарэлы запіс замест таго, каб дадаваць другі.

Канфігурацыя на баку хоста і яе цана

Заданне адрасу на хосце цалкам здымае пытанне супадзення. Інтэрфейс падымаецца з гэтым адрасам незалежна ад таго, ці адказвае DHCP, і менавіта гэтага вы хочаце ад машыны, якая павінна быць даступная пасля перазапуску роўтара.

Цана — валоданне. Цяпер вы самі падаяце прэфікс, шлюз і рэзалверы, і павінны самі трымаць адрас па-за дынамічным пулам. На Ubuntu з netplan гэта нясе /etc/netplan/01-vpn.yaml:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

Карыстальнікі NetworkManager дасягаюць таго ж стану з nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, затым nmcli con up "Wired connection 1". Прымяніце netplan з netplan try пры першай спробе, а не з netplan apply; шлюз з памылкай выводзіць бокс з сеткі і пакідае вас шукаць кансоль.

Тым не менш трымайце адпаведнае рэзерваванне. Яно не лішняе. Запіс фіксуе адрас на баку роўтара і не дазваляе DHCP-серверу выдаць гэты адрас гасцявой прыладзе, калі хто-небудзь пазней пашырыць пул.

Стабільны адрас LAN — не публічная кропка ўваходу

Накіруйце перанакіраванне порта на 192.168.50.10, і правіла перажыве любое змяненне на баку LAN. Яно не дае вам стабільнага інтэрнэт-адрасу. Ваш публічны IP належыць правайдэру і можа змяніцца пры перападключэнні або замене мадэма, для гэтага і існуе дынамічны DNS.

За NAT узроўню аператара публічнага IPv4 для перанакіравання наогул няма, і ніякае рэзерваванне яго не стварае. Спачатку праверце старонку WAN роўтара: калі адрас знаходзіцца ў агульным дыяпазоне, уваходнае перанакіраванне не можа працаваць, наколькі б чыстым ні было рэзерваванне.

Трэці адрас — гэта тунельны пул, часта нешта накшталт 10.8.0.0/24. Гэтыя адрасы існуюць толькі ўнутры тунеля і ніколі не з’яўляюцца ў LAN. Блытаніна іх з адрасам LAN сервера — гэта тое, як порт у рэшце рэшт накіроўваецца да кліента, які анлайн толькі пакуль падключаны.

Правярайце шлях у тым парадку, у якім ён ламаецца

Пачніце з роўтара. Параўнайце запіс табліцы арэндаў з мэтай рэзервавання; калі сервер узяў адрас пула, ідэнтыфікатар няправільны, і ip link show на хосце дасць вам значэнне для параўнання.

Затым хост. ip -4 addr show eth0 павінен паказваць чаканы адрас і прэфікс. Другі адрас на тым жа інтэрфейсе звычайна азначае, што DHCP усё яшчэ працуе побач з вашай статычнай канфігурацыяй.

Затым перанакіраванне. Пераканайцеся, што мэта па-ранейшаму роўная адрасу, які вы толькі што праверылі, і што нешта слухае праз ss -lntp. Перанакіраванне на зачынены порт звонку выглядае гэтак жа, як зламанае перанакіраванне.

Скончыце звонку, на тэлефоне з выключаным Wi-Fi. Гэты адзін тэст аддзяляе «лакальны адрас няправільны» ад «публічная дасяжнасць зламаная», дзве праблемы, якія гэтая налада пастаянна змешвае.

Запішыце тры адрасы — LAN, публічны і тунельны пул — і адзначце, якая сістэма валодае кожным. Калі наступным месяцам злучэнне сарвецца, вы будзеце ведаць, які правяраць, замест таго каб мяняць усе тры адразу.