VPN адаптерът показва /32: това не значи една дестинация

Адаптерите показват 255.255.255.255 и често се стига до извода, че VPN достига точно един адрес. Такова четене обърква собствения адрес на клиента с набора от дестинации, маршрутизирани през тунела. На интерфейс точка-точка или маршрутизиран интерфейс двете са различни обекти и само едното от тях ограничава достижимостта. Митовете живеят, защото маската изглежда като маската на подмрежата, която хората са учили в Ethernet.

Митът: маска на хост значи един достижим хост

Назначаването на /32 казва на интерфейса кой адрес принадлежи на този край на връзката, а при връзка точка-точка това е всичко, което означава. Адресът на партньора е отделно поле, а маршрутите, които казват какво е отвъд партньора, са отново отделни. Нищо в маската не описва отдалечената мрежа, защото маската не е мястото, където се описват отдалечените мрежи. Да се чете като граница на достижимост е като да четеш номера на собствената си къща като списък на всеки адрес, който можеш да посетиш.

Объркването има реална основа: в Ethernet маска на хост наистина би означавала един адрес в този сегмент. Тунелът не е Ethernet сегмент и какво минава през него решава таблицата за маршрутизация на клиента, а не маската. Затова една и съща /32 може да стои пред цял център за данни.

Четете адреса и маршрутите като отделни обекти

Изведете интерфейса и таблицата заедно, после ги четете като два отговора на два въпроса. Адресът отговаря кой е този край; маршрутите отговарят накъде може да отиде трафикът. Трети въпрос — кои дестинации разрешава шлюзът — изобщо не се вижда на клиента. Справочникът за адреси на iproute2 описва полетата за локален адрес, партньор и маршрут по префикс поотделно точно поради тази причина.

ip addr show tun0
ip route show
ip route get 10.60.5.10

В Windows същото разделение съществува между списъка с адреси и таблицата за маршрутизация, а командата за търсене е най-бързият начин да видите кое печели за конкретна дестинация. Ако търсенето върне тунелния интерфейс, клиентът ще изпрати пакета там. Ако върне физическия адаптер, клиентът никога не пита VPN и никакво разрешение от страна на сървъра няма да промени това. Проверявайте дестинацията, която наистина ви трябва, а не общ публичен адрес.

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

Спрете, ако търсенето сочи към грешния интерфейс. Това е проблем с маршрутизацията на клиента и се оправя на клиента.

Защо разширяването на маската обикновено влошава нещата

Промяната на назначаването на /24, за да изглежда като офис LAN, може да създаде префикс на връзката: ядрото вече смята, че цялата /24 е директно прикачена към тунелния интерфейс. Трафикът към адреси, които трябва да минават през шлюза, тогава се изпраща, сякаш съсед е на връзката. Резултатът е черна дупка, която изглежда като отказ на сървър.

Тя също скрива истинския проблем: липсващ маршрут или липсващо разрешение на шлюза. Нито едно от двете не се създава от по-широка маска и двете оцеляват след промяната. Ако дизайнът изисква по-голям префикс на интерфейса, това е решение за използвания модел на интерфейс, взето с документацията в ръка. Копирането на маска от екранни снимки на друг продукт не е това решение.

Ако маршрутът за отдалечения префикс липсва, поправете осигуряването му. Ако е налице, а връзката все още се отхвърля, маската никога не е била диагнозата.

Когато маршрутът е правилен, а потокът все още се проваля

Правилният маршрут доказва само, че клиентът ще изпрати пакета. Шлюзът все още трябва да приеме дестинацията, обратният път трябва да съществува за назначения адрес, а услугата трябва да разреши потока. Тествайте тези три неща поотделно: търсенето на клиента, разрешения обхват на шлюза и заявка към един необходим сървър. Успешната автентикация преди тези три да са налице е нормална и точно затова свързан клиент може да не достигне до нищо.

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

Пазете мрежовите обекти и разрешенията на групите при техния собственик в услуга, управлявана от устройство. Това, което на клиента се казва да достигне, и това, което му е разрешено да използва, са различни настройки, често на различни екрани. Промяна на едното и тестване на другото е начинът, по който една заявка подскача между два екипа.

Митът, който трябва да оттеглим, е, че маската е граница на достижимост. Четете адреса, маршрутите и политиката на шлюза като три отделни факта и /32 спира да изглежда като ограничение и започва да изглежда като нормално назначаване на тунел.