IKEv2-uitruiling werk, dan misluk verifikasie: waar

’n Kliënt wat ’n IKEv2-antwoord ontvang, het bewys dat die gateway bereikbaar is, dat beide kante ’n voorstel kan onderhandel en dat die aanvanklike sleuteluitruiling voltooi is. Dit het egter nie bewys dat iemand geverifieer is nie. Die volgende uitruiling dra identiteite, sertifikate of EAP, en dit is gewoonlik waar die verbinding stop. Om te lees watter van daardie kontroles misluk het, is die hele diagnose, en die foutboodskap alleen sê dit selde.

Kontrole 1: lees die fase, nie die boodskap nie

’n Verwerping kan van drie plekke kom: die kliënt wat die bediener se identiteit weier, die gateway wat die kliënt se bewys weier, en ’n eksterne verifikasiediens wat die rekening weier.

Elkeen produseer ’n ander logreël op ’n ander masjien, en elkeen het ’n ander oplossing. ’n Weiering van die bediener se sertifikaat aan die kliënt se kant is ’n vertroue- of naamprobleem op die kliënt; ’n weiering van die kliënt se sertifikaat aan die gateway se kant is ’n vertroueprobleem op die gateway; ’n EAP-fout is ’n rekening- of backend-probleem. Die boodskap wat jy sien, is gewoonlik die kliënt se opsomming van een van hierdie, en daarom is die gateway se log net so belangrik soos die kliënt s’n.

Kontrole 2: watter identiteit is nagegaan

’n Kliënt kan die bediener se sertifikaat of die verwagte identiteit verwerp voordat enige gebruikersbewys aangebied word, en ’n werkende bedieneradres is nie ’n plaasvervanger vir daardie kontrole nie. Die identifiseerder wat die kliënt verwag, moet ooreenstem met wat die gateway aanbied, wat ’n konfigurasiefeit is eerder as ’n netwerkfeit.

In strongSwan-terme is dit rightid aan die kliëntekant en die gateway se eie identiteit aan die ander kant, en ’n verskil misluk voordat EAP eers bespreek word.

Die gateway kan, afsonderlik, die kliënt se sertifikaat, sy sleutelbewys of sy rekeningverifikasie verwerp, en dié drie is nie uitruilbaar nie. Om ’n gebruikerswagwoord te herstel kan nie ’n toestelsertifikaat vernuwe nie, en om ’n toestelsertifikaat te herinstalleer kan nie ’n verkeerde bedieneridentiteit regstel nie. Vir sertifikaatfoute, kyk eerste na die klok, dan na die vertroueketting, dan na die verwagte identifiseerder; ’n kliënt wie se klok minute verkeerd is, misluk ’n geldigheidskontrole wat soos ’n vertrouefout lyk. swanctl --list-certs aan beide kante wys wat elke kant werklik het.

Kontrole 3: as EAP in die spel is

Die kliënt en die bediener moet oor ’n ondersteunde metode saamstem, en die backend moet die identiteit wat verskaf word, aanvaar.

’n Gebruikersnaam mag ’n domeinagtervoegsel of ’n spesifieke rekeningformaat nodig hê wat die ontplooiing vereis, en die formaat word gedokumenteer in plaas daarvan om te raai. Om die operateur se gedokumenteerde velde te verskaf is vinniger as om variante te probeer, en dit vermy ’n tweede probleem: herhaalde pogings kan ’n rekeningversperring veroorsaak, wat dan die oorspronklike fase agter ’n nuwe fout versteek. As die metode EAP-MSCHAPv2 teen ’n gids is, mag die fout aan die gids behoort eerder as aan die VPN.

Moenie identiteitsprobleme toets deur identiteitskontroles af te skakel nie. Dit verander ’n diagnoseerbare fout in ’n ondiagnoseerbare een en laat die verbinding swakker as voorheen.

Kontrole 4: wat gebeur ná ’n suksesvolle aanmelding

Sodra IKE_AUTH voltooi is, bepaal CHILD_SA-onderhandeling watter verkeerselektors geïnstalleer word, en dit is waar ’n verbinding kan slaag en steeds niks deurlaat nie.

’n Nuwe werkende aanmelding onthul dikwels ’n selektor- of roeteprobleem wat voorheen agter die verifikasiefout verborge was. As die tonnel opkom en ’n toepassing steeds nie sy bestemming kan bereik nie, kyk na die onderhandelde selektors en die roetes eerder as weer na die identiteit. Om op daardie punt identiteitsinstellings te verander, mik op die verkeerde fase en breek gewoonlik ’n werkende aanmelding. Bevestig met swanctl --list-sas, wat die kinders en hul selektors afsonderlik van die IKE SA wys.

Kontrole 5: wat om aan ondersteuning te gee

’n Gereinigde tydlyn en die presiese verwerping is meer werd as ’n volledige diagnostiese uitvoer, en die uitvoer kan private sleutels of bewyse bevat wat jy nie behoort te deel nie.

Teken die tyd met die tydsone aan, die weergawes van kliënt en gateway, die metode, die identiteitsstring wat aangebied is eerder as die wagwoord, en die presiese fase wat dit verwerp het. strongSwan se IKEv2-konfigurasiedokumentasie beskryf die identiteits- en EAP-instellings wat hierdie uitkomste bepaal, en dit is die verwysing om te lees voordat jy ’n veld verander. Verander dan een ding en toets ’n vars verbinding, want ’n gekaste sessie sal jou van die ou konfigurasie vertel.