CIDR на група в Access Server: адреси на членове или мрежа на ресурси

Две полета в група на Access Server приемат CIDR и на пръв поглед изглеждат един и същ вид входни данни: едното описва адресите, които получават членовете на VPN, другото — мрежите, до които тези членове могат да стигнат. Грешното поле се приема без грешка и точно това прави грешката скъпа: първото променя плана за адресиране на тунела, второто решава кои дестинации са разрешени.

Същият синтаксис, други въпроси

Питайте какво именува стойността. CIDR за адреси на членове отговаря кои вътрешни адреси получават свързващите се клиенти и механизмът за разпределяне го използва преди да тръгне трафик. CIDR за ресурс отговаря кои дестинации може да ползва групата и правилата за достъп го използват при оценка на пакет.

Последствията са противоположни. LAN на дестинация, поставена в полето за пул, може да раздаде адреси, които вече съществуват в тази LAN, или да измести пула и тихо да счупи всяко правило на защитната стена, писано за стария диапазон. Пул в правило за достъп не дава нищо полезно, защото там не живее нито една дестинация. И двете изглеждат като вдигнат тунел, но нещо не е наред.

Разпределение: адресното пространство на членовете

Пулът не бива да се застъпва с нито една LAN, до която член може да стигне, нито с друг VPN пул. Ако два обекта използват 10.90.40.0/24 за членове, член на единия не може да маршрутизира към другия без транслация и никакво правило за достъп не оправя това.

Режимът на разпределяне също е важен. Динамичният пул дава следващия свободен адрес, а статичното назначаване за потребител го заковава. Статичното е нужно, когато правила на защитната стена или мониторинг сочат отделни членове; прочетете адреса на тунела на един свързан член преди и след всяка промяна на това поле.

Разрешение: мрежите на дестинациите са в правилата за достъп

Достижимостта се изразява в правилата за достъп: група или потребители, мрежа или услуга на дестинацията и метод на достъп. Тук умират повечето недовършени настройки: правилото може да маршрутизира трафика към дестинацията или да прави NAT и двете искат различни неща от мрежата. Маршрутизираният път изисква страната на дестинацията да знае как да върне трафика към VPN пула, докато NAT крие членовете зад адрес, на който дестинацията вече вярва. Документация за групите в Access Server държи мрежите на групата отделно от правилата за достъп.

Разрешената дестинация все още има нужда от работещ път. Правилото разрешава, маршрутът доставя, пътят за връщане отговаря, а услугата на хоста приема. Четири неща, четири места и само първото е в правилото за достъп. Зелено разрешение с мъртъв traceroute обикновено значи пътят за връщане липсва на шлюза на дестинацията, а не че правилото е грешно.

Третият обект: подмрежа на клон зад шлюз

Да обявите, че определен клиент притежава подмрежа е маршрутно твърдение за обект, а не назначаване на адреси и не разрешение. Членовете все още получават адреси от пула и все още им трябва правило за достъп, за да ползват тази LAN на клона.

Отделянето на трите се отплаща при преглед. Подмрежа на клон, записана като адресно пространство на членове, изглежда вярна на екранна снимка и чупи разпределението за всички в групата. Същата подмрежа, записана само в правило за достъп, дава достъп без твърдението за собственост, така че връщащият трафик няма къде да отиде.

Как да разберете кой от трите гледате

Четете етикета заедно със съседите му. Поле до режим на разпределяне, размер на пул или override за потребител е за разпределението. Поле до избор на група, услуга или порт и метод на маршрутизация е за разрешението. Версиите преименуват нещата, но съседите остават приблизително на местата си.

После проверявайте с един член, а не с цялата група: ефективната му група, назначения адрес на тунела и правилото, което разрешава желаната дестинация. Потвърдете маршрута, NAT или маршрутизирания път, връщащия трафик и разрешението на услугата в този ред и променяйте само полето, което отговаря на доказаното несъответствие.