AWS Client VPN: најавата успева, но подмрежата е недостапна

Вашиот клиент вели Connected, сертификатот е валиден, а страницата на интранетот сè уште завршува со истек на време. Овој јаз речиси никогаш не е автентикација. AWS Client VPN ги авторизира одредиштата одделно од најавата, а двата вообичаени причини се вредност на групата што не се совпаѓа со она што го испратил давателот на идентитет и поконкретно правило за одредиште што го победува широкото. И двете се видливи во конфигурацијата на endpoint кога знаете каде да гледате.

Најавата успеа; правилото не се совпадна

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

Започнете со потврда дека endpoint има правило за авторизација чие одредиште ја содржи адресата што не поминува. Ако нема соодветно правило, врската се однесува точно; недостига политиката.

Од каде всушност доаѓа вредноста на групата

Во Active Directory полето access-group ја содржи SID на групата, а не нејзиното прикажано име. Во SAML федерацијата ја содржи групната ID или името што конфигурираниот SAML атрибут за група навистина го носи. Копирајте ја вредноста од assertion или од пребарувањето во директориумот, а не од вики страница.

Групата IAM е друга контролна рамнина. Дозволата за администрирање на Client VPN endpoint не ја прави групата IAM корисничка VPN група, а лепењето на името на IAM групата во полето access-group не го претвора во AD SID или вредност на SAML атрибут.

Група со слично име во друг директориум не докажува ништо. Проверете го методот на автентикација на endpoint и членството или assertion на корисникот во истиот систем.

Победува најдолгиот префикс, вклучително 0.0.0.0/0

Авторизацијата се оценува според најдолгото совпаѓање на префикс, а правилото за сите одредишта се оценува последно, не прво. Додадете правило 10.46.0.0/16 за Engineering и правило 0.0.0.0/0 за сите, и корисник надвор од Engineering сè уште не може да стигне до 10.46.20.10 преку широкото правило.

Тука поправката може да тргне наопаку. Бришењето на тесното правило го враќа пристапот на корисникот и истовремено ја дава таа подмрежа на секој идентитет опфатен со широкото правило. Изградете матрица група-кон-мрежа пред да избришете нешто и запишете кои групи треба да достигнат кој опсег. Овие правила само дозволуваат; нема запис за забрана со кој би изрежале исклучок од широко дозвола.

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

Одделете ја авторизацијата од патеката на податоци

Совпаднато правило не е рута. Endpoint бара поврзана подмрежа и запис во табелата за рутирање за одредиштето, а безбедносната група на целниот ресурс мора да го прими сообраќајот. Повратниот сообраќај и DNS исто така мора да работат.

Тестирајте корисник што треба да успее и корисник што треба да остане исклучен. Двата можат да се најават, но само едниот стигнува до подмрежата, и таа разлика е доказот што го сакате.

Ако IP адресата работи, а името на домаќинот не, погледнете го resolver пред да ја допрете авторизацијата. Ако ниту една рута не ја покрива адресата, поправете го поврзувањето или табелата за рутирање. Ако пакетот пристигне, а услугата го одбие, следна станица е политиката на таа услуга. Проширувањето на матрицата за авторизација на сите корисници крие кој од тие слоеви навистина бил скршен.

Пред да го затворите тикетот, запишете го изворот на идентитет, точната вредност на групата, префиксите на одредиштето и рутата што го носи сообраќајот. Тој запис ја претвора следната пријава за поврзано без пристап во споредба од две минути наместо уште еден круг нагаѓања.