Die relay werk in drie bene, en net die middelste een kruis die VPN. ’n Kliënt stuur ’n uitsending op die taksegment, die ASA verander daardie uitsending in ’n unicast-versoek aan die DHCP-bediener, en die bediener antwoord die relayadres eerder as die kliënt. Volg die bene in daardie volgorde, en die meeste gevalle van “relay is stukkend” los op na ’n ontbrekende beleid of ’n verkeerd geleesde setroute-reël.

Been een: aktiveer relay op die kliëntgerigte koppelvlak

Op die tak-ASA is relay ’n eienskap van die koppelvlak wat na die kliënte kyk. Die bediener kan globaal verklaar word met sy bereikbare koppelvlak, of onder daardie kliëntgerigte koppelvlak sodat die roetebeheerder die uitgang kies. Daardie twee vorms is nie uitruilbaar nie, en om die verkeerde een te kopieer is die eerste plek waar ’n deurloop skeefloop.

Kontroleer die lopende konfigurasie voordat jy iets verander: watter koppelvlak relay geaktiveer het, watter bedienerformaat teenwoordig is, en of setroute aan die kliëntkoppelvlak gekoppel is. As die ASA ook ’n DHCP-bediener vir ’n ander segment bedryf, stop en lees die beperkingslys; bediener en relay kan nie albei op dieselfde kas geaktiveer word nie.

Die relay plaas sy eie kliëntgerigte adres in die poortwegadresveld. Daardie adres is waaraan die bediener sal antwoord, so dit moet van die verre site af oor die tonnel bereikbaar wees, nie net plaaslik nie.

Been twee: dra ASA-gegenereerde verkeer oor die tonnel

Dit is die stap wat mense oorslaan. ’n Beleidgebaseerde site-tot-site VPN word gewoonlik gebou vir verkeer tussen subnette, en die relayversoek word deur die ASA self gegenereer. As die tonnel se toegangslys en die kriptokaart net tak-gasheer-na-bediener-subnet-vloei pas, mag die relaypakket nooit die tonnel binnegaan nie. Kontroleer die toegangslys in albei rigtings, nie net die tak-na-bediener-lyn nie.

Bevestig dat die interessante verkeer die ASA se relaybron en die bedieneradres dek, en dat die terugrigting ook toegelaat word. Op ’n VTI-gebaseerde ontwerp is die roetebesluit eenvoudiger, maar relayondersteuning oor VTI het in ’n spesifieke uitgawe gekom; die ASA DHCP-gids identifiseer 9.14(1), so kontroleer die beeld voordat jy ’n VTI-voorbeeld op ’n ouer toestel kopieer.

’n Ping van die ASA na die bediener bewys op sigself min. Dit kan slaag deur ’n ander pad, met ’n ander bronadres, of onder ’n beleid wat die relay se pakkette nie pas nie.

Been drie: lees die antwoord en die setroute-opsie

RFC 2131 sê die bediener stuur sy antwoord na die adres in giaddr wanneer daardie veld nie nul is nie. Dus moet die terugpad na die relayadres roeteer, en die tonnelbeleid moet die rigting bediener-na-relay toelaat. As die versoek deurgekom het maar die aanbod nooit arriveer nie, is dit waar om te kyk.

Skei dan twee dinge wat dieselfde klink. Die setroute-sleutelwoord verander of voeg die verstekroeteerder-opsie by wat die ASA aan die kliënt gee. Dit installeer nie ’n roete op die ASA nie en dit skep nie VPN-beleid nie. ’n Kliënt wat ’n adres kry maar niks kan bereik nie, is dikwels ’n setroute- of omvangprobleem, nie ’n tonnelprobleem nie. Toets dit met ’n kliënt wat geen statiese poortweg het nie en kyk watter verstekroeteerder in die aanbod verskyn.

Lees die aanbod van begin tot einde: aangebode adres, masker, verstekroeteerder, DNS en huurtyd. Laat die huur dan vernuwe. ’n Relay wat een keer werk en by vernuwing misluk, het gewoonlik ’n omvang-, huur- of terugpadprobleem wat die eerste uitruiling weggesteek het.

Wat ek nagaan voordat ek dit reg noem

Begin by die kliënt en vang die uitsending, bevestig dan dat die ASA dit met sy eie adres as giaddr deurgestuur het. Aan die verre kant, bevestig dat die bediener daardie versoek gesien het en ’n omvang gekies het wat by die tak pas. Terug by die tak, bevestig dat die kliënt die aanbod aanvaar het en sy poortweg kan bereik.

As enige been stil is, kontroleer die ooreenstemmende beleid of roete eerder as om nog ’n relayverklaring by te voeg. Die relaykonfigurasie is gewoonlik reg teen die tyd dat iemand eskaleer; dit is die tonnelbeleid of die terugroete wat verander het.

Skryf die drie bene in die veranderingsrekord: kliëntgerigte koppelvlak, VPN-beleid wat relayverkeer dek, en die bediener se roete terug na giaddr. Daardie rekord is wat die volgende takbou ’n herhaalbare taak maak eerder as ’n ontsporingsessie. Dit sê ook vir die volgende ingenieur watter opdraguitset eerste versamel moet word.

Verwante artikels