Firebox-geoliggingweiering: vind eers die VPN-toegangstadium

Iemand in 'n ander land kan nie konekteer nie, en die eerste instink is om na die reël te kyk wat toegang tot interne hulpbronne verleen. Daardie reël loop ná toelating, so dit kan nie die ding wees wat die tonnel verwerp nie. Die blokkerende stadium is iewers in die toegangsroete, en die Firebox het meer as een toegangsroete, afhangend van die VPN-diens. Werk die kontroles in volgorde deur en stop sodra een van hulle die weiering verklaar.

Kontrole 1: benoem die inkomende diens

Vir Mobile VPN met SSL, Access Portal en BOVPN oor TLS is die inkomende toegang die WatchGuard SSLVPN-beleid. Pas die beoogde beperking daar toe, op die werklik gekonfigureerde diens, eerder as om dit af te lei uit 'n gebruikerstoegangsbeleid wat later loop.

IPsec volg 'n ander roete. Die ingeboude IPSec-beleid laat eksterne IPsec-verkeer na die Firebox toe vir die toepaslike tak- en mobiele VPN-dienste, en dit het voorrang bo 'n handmatig geskepte IPSec-beleid. As jou kliënt IKEv2 is, is jy op daardie tweede roete, en die SSLVPN-beleid is irrelevant.

Om dit verkeerd te kry, is die mees algemene vermorste middag op hierdie gebied: 'n beleid wysig wat nooit die pakkie sien nie, en dan tot die gevolgtrekking kom dat die beperking nie werk nie.

Kontrole 2: lees die weiering, nie die teorie nie

Maak een beheerde toegestane poging en korreleer vier dinge: die kliënt se openbare bronadres, die toegangsdiens wat dit getref het, die beleid wat gepas het, en enige weieringsrede in die log. WatchGuard se IKEv2-probleemoplossingsriglyne noem dat geoligging en standaardpakkiehantering verkeer kan weier voor toelating deur die ingeboude beleid, wat beteken die weiering wat jy sien kan 'n stadium noem wat jy nie oorweeg het nie.

Landklassifikasie volg die waargenome netwerkbron. 'n Rondreisende gebruiker, 'n stroomop NAT of 'n ander goedgekeurde roete kan verander wat die Firebox sien, so bevestig die adres eerder as die gebruiker se beskrywing van waar hulle is. Vra vir die openbare adres wat die kliënt sien, en vergelyk dit met die bron in die Firebox-log. Wanneer dié verskil, volg die klassifikasie 'n roete wat niemand genoem het nie.

Kontrole 3: is die ingeboude beleid nog die eienaar?

As dit lyk of 'n handmatige IPSec-beleid geïgnoreer word, kyk of die ingeboude een nog geaktiveer is. 'n Handmatige reël wat deur 'n ingeboude reël met hoër voorrang oorskadu word, en 'n handmatige reël wat die enigste toelating is, is verskillende konfigurasies met dieselfde voorkoms in die koppelvlak.

Besluit watter een jy bedoel om die roete te laat besit. As dit die handmatige beleid is, moet die ingeboude een vir daardie verkeer gedeaktiveer word, en dit is waar die volgende kontrole begin.

Kontrole 4: beplan die vervanging voordat jy deaktiveer

Deaktivering van die ingeboude IPSec-beleid verwyder sy toelating vir die betrokke VPN-dienste. Dit sluit taktonnels in waaraan jy dalk nie dink terwyl jy een mobiele gebruiker se verbinding regmaak nie.

Beplan eers die volledige vervanging: watter dienste toelating nodig het, watter bronbestekke hulle kry, en hoe jy die boks sal bestuur as die verandering verkeerd loop. Hou 'n onafhanklike bestuurs- en herstelroete oop, want 'n fout hier kan die tonnel verwyder wat jy sou gebruik om dit reg te maak. Teken die herstelstappe in die veranderingsrekord aan, insluitend hoe om die boks te bereik as die VPN-roete weg is. Toets dan hernuwing, nie net die eerste verbinding nie.

Aktiewe verbinding en latere heronderhandeling kan albei van toelating afhang. 'n Verandering wat werk vir die sessie wat jy getoets het en by die volgende sleutelherruiling misluk, is 'n klassieke uitkoms van die vervanging van toelating sonder om hernuwing te toets.

Kontrole 5: hou identiteit apart van ligging

Geoligging voeg konteks by 'n toegangsbesluit. Dit stel nie vas wie die gebruiker is nie, en dit moet nie gateway-identiteitskontroles, rekeningmagtiging of MFA vervang nie.

As die besigheidsvereiste net goedgekeurde gebruikers vanaf goedgekeurde plekke is, het jy albei kontroles nodig. 'n Liggingreël wat 'n hele land toelaat, is nie 'n plaasvervanger vir verifikasie nie, en 'n geverifieerde gebruiker in 'n geblokkeerde land is 'n beleidsvraag eerder as 'n fout.

Kontrole 6: teken dit aan en verifieer albei roetes

Skryf die diens neer, die toegangsbeleid, die beoogde liggingsbestek, die uitsonderings en die hersteleienaar. Toets dan die mobiele roete en ten minste een terreinroete ná die verandering, sodat die beperking aan die diens geheg bly waarvoor dit ontwerp is.

Laastens, lees weer die weiering waarmee jy begin het. As dit van 'n liggingweiering na 'n verifikasie- of magtigingsfout verander het, is die toegangsprobleem opgelos en is 'n ander een nou sigbaar. Die WatchGuard IKEv2-weieringsriglyne is die verwysing vir die stadiumordening hierbo beskryf.