Зашто хост у LAN-у шаље ARP за адресу OpenVPN клијента

Проблеми са достижношћу између хоста у LAN-у и VPN клијента често воде натраг до самог плана адреса. Дајте том хосту сучеље на 10.0.100.0/22 и он ће сваку адресу од 10.0.100.0 до 10.0.103.255 третирати као изравно повезану, укључујући скупину клијената тихо смештену на 10.0.101.0/24. Одговор никада не иде усмеравачу, јер са становишта хоста није укључен ниједан усмеравач. Пакет је адресиран суседу и тражи се на жици.

Тај механизам стоји иза целе породице извештаја: тунел је активан, сервер има руту, а хост у LAN-у ипак не може да достигне клијента.

Префикс /22 који гута /24

Читајте префикс као распон, а не као низ знакова. Префикс /22 садржи 1024 адресе, а 10.0.100.0/22 протеже се од 10.0.100.0 до 10.0.103.255, па скупина на 10.0.101.0/24 лежи цела унутар њега. Грешка преживи преглед јер први октети скупине изгледају другачије од првих октета LAN-а, а само трећи октет открива садржавање. Запишите оба распона бројчано пре него што их прогласите одвојеним.

Исто садржавање може се појавити и обрнуто. Скупина која изгледа слободна јер је тренутно нико не користи ипак може пасти унутар префикса који оглашава неки усмеравач локације, а план адреса једини је документ који то показује.

Изравна веза значи ARP, а не усмеравање

Када хост са сучељем /22 шаље на 10.0.101.25, језгро упоређује одредиште са префиксом сучеља и проналази подударање. Пакет постаје разрешавање суседа уместо усмереног пакета, а на Ethernet-у је разрешавање суседа ARP захтев за ту адресу. Ако адреса припада VPN клијенту иза усмереног приступника, ниједан хост у LAN-у је не поседује, па захтев остаје без одговора и пакети се одбацују. Тунел није крив, а клијент никада не види саобраћај.

Зато квар изгледа асиметрично и повремено испрекидано. Хост VPN често достигне LAN јер његове властите руте показују у правом смеру, док хост у LAN-у не може да одговори, и све што предмеморише застарео ARP запис чини да симптом трепери.

TUN, TAP и шта сваки преноси

Уређај TUN преноси IP пакете, а уређај TAP преноси Ethernet оквире. Усмерена TUN веза не мора да преноси ARP да би пружила достижност IP-а, и управо је зато неодговорени захтев горе очекиван, а не покварен. TAP са намерним мостом може да прошири broadcast домен и оспособи ARP, али мења шта клијент види, захтева крајње тачке које подржавају исто уоквиривање и прерада је мрежног модела, а не поправка преклапајућег префикса. Прелазак усмерене имплементације на TAP ради излечења грешке плана адреса мења мали проблем за већи.

Забележите где се ARP захтев појавио и који га је систем послао пре него што изведете закључке. Пошиљалац вам говори шта мисли о одредишту, а не шта тунел ради.

Пројектујте скупину која не може да се преклапа

Одаберите скупину изван сваког повезаног префикса и сваког оглашеног префикса локације, затим додајте руте које је чине достижном у оба смера. Распон попут 10.8.0.0/24 у неискоришћеном делу плана лако је промислити, а LAN који га мора достићи добија статичну руту која показује на VPN сервер. Мењајте заједно доделу, оглашене руте, дозвољене изворне адресе и правила заштитног зида, јер описују један дизајн, а не четири поставке.

Изворни NAT на серверу може сакрити скупину иза адресе усмериве из LAN-а и легитимно је миграционо средство. Преписује и извор, па LAN губи могућност приписивања веза појединачним клијентима и примене правила по клијенту.

За прихват употребите стварно додељену адресу стварног клијента и стварни захтев апликације са хоста у LAN-у, затим потврдите да одговор следи планирани приступник, а не жицу.