MAC stem nie ooreen in IKE: die kontrole van die gedeelde sleutel het misluk

Jou Cloud VPN-log wys 'n poging met 'n gedeelde sleutel gevolg deur MAC mismatched, en die eerste instink is dikwels om na 'n adresprobleem te soek. In hierdie vertakking is MAC 'n boodskapverifikasiekode: 'n waarde wat oor die uitruiling met die onderhandelde sleutel bereken word. Die eweknie het sy eie berekening met die waarde wat dit ontvang het vergelyk, en hulle het verskil. Geen netwerkkaart is betrokke nie, en geen koppelvlakinstelling verander daardie vergelyking nie.

Twee toestande veroorsaak dit in die praktyk: die geheime aan die twee kante is nie dieselfde waarde nie, of die identiteite wat gebruik word om die geheim te kies stem nie ooreen nie. Beslis watter deur die paar te lees, nie die enkele tonnel nie.

Wat die fase bewys

Die kontrole loop nadat beide kante hul aanvanklike parameters uitgeruil en hulself geïdentifiseer het. Dit kies kandidaat-gedeelde sleutels vir die plaaslike en afgeleë identiteite en probeer die ontvangde verifikasiedata valideer; wanneer niks valideer nie, word die diagnose uitgestuur. Dit is 'n sterk stelling oor verifikasie en 'n swak stelling oor die oorsaak, want dit sê nie watter kant verkeerd is nie.

Vroeëre sukses dra nie na hierdie kontrole oor nie. 'n Voltooide IKE_SA_INIT, of 'n NAT-opsporing-lading wat die verwagte waardes teruggegee het, bewys die eweknieë kan praat. Dit bewys niks oor of hulle 'n geheim deel nie.

Twee konfigurasiefoute, een boodskap

Die eerste is 'n werklike geheimverskil, en dit is gewoonlik 'n voorsieningsongeluk: 'n gegenereerde waarde wat op een konsole geïnstalleer en op die ander oorgetik is, 'n sleepkarakter wat aan een kant oorleef het, of 'n aanhalingsteken wat saam met 'n plak gekom het. Die tweede is 'n identiteitsverskil, waar die geheim korrek is maar die identiteit wat die eweknie voorhou 'n ander inskrywing kies, sodat die regte geheim nooit probeer word nie. Albei lewer dieselfde reël, en daarom kos raai 'n middag.

Vergelyk die paar voordat jy aan enige geheim raak. Pas die tonnel, die eweknie-eindpunt, die tydvenster en die afgeleë konfigurasie, want twee oortollige tonnels kan verskillende geheime hou en die skerm voor jou is dalk nie die een wat misluk het nie.

NAT-opsporing is 'n ander fase

NAT-opsporing vra hoe pakkette herskryf word, nie wie die eweknie is nie. 'n Klantpoort voor NAT verifieer steeds korrek wanneer sy gekonfigureerde identiteit die een is wat die eweknie verwag, en 'n NAT-probleem wys as 'n voorstel- of poortverskil eerder as 'n mislukte verifikasievergelyking.

Moet nie 'n ou stelling oor een verskafferweergawe na 'n huidige ontplooiing oordra nie. Wat NAT-traversering in jou weergawe vereis, hoort in sy eie dokumentasie, en die frase MAC mismatch is geen bewyse daarvoor of daarteen nie.

Beslis uit die paar, nie die skerm nie

Lees beide konfigurasies langs mekaar met die geheim verwyder, en vra dan drie vrae. Is die identiteit aan elke kant presies wat die ander verwag, karakter vir karakter? Gebruik beide kante dieselfde IKE-weergawe en dieselfde verifikasiemetode? Stem die tonnel wat misluk met die konfigurasie wat jy lees ooreen? 'n Nee op enige van dié beslis die herstel sonder om aan die geheim te raak.

As al drie skoon is, vervang die geheim deur die goedgekeurde werkvloei eerder as om daaromheen te redigeer.

Nadat die eweknie verifieer het

Sodra verifikasie slaag, is die volgende falingsoppervlak die kind-sekuriteitsassosiasie: voorstelle en verkeerskiesers. Om 'n geheim te roteer wat reeds aanvaar is, kan nie 'n kindfaling regmaak nie, en dit verleng die onderbreking. Lees die kindtoestand, dan die kiesers en beskermde reekse aan beide kante, en pas die Cloud VPN-probleemoplossing leiding by die fase wat werklik misluk het.

Korreleer vars logs van beide kante vir dieselfde paar en dieselfde venster. Een kant alleen gee 'n uitspraak sonder die ander kant se insette, wat die dubbelsinnigheid is wat die boodskap in die eerste plek veroorsaak het.

Wat om nie af te lei nie

Lees nie die boodskap as 'n eis om MAC-adresse te verander nie, en publiseer nie die gedeelde geheim terwyl jy om hulp vra nie; 'n uittreksel wat die sleutel bevat, moet die sleutel verwyder hê, nie die log behou nie. Moet ook nie 'n roeteringsfout aanneem nie, want eweknieë wat mekaar nie kan bereik nie, lewer glad geen verifikasievergelyking nie. En veralgemeen nie 'n gedokumenteerde beperking van een produkfamilie na elke IPsec-implementering nie.

Teken die mislukte paar aan, die tonneltoestand voor en na, en watter van die twee toestande jy verander het. Daardie rekord maak die volgende gebeurtenis 'n vyfminuut-kontrole.