ASA DHCP-relay oer in site-to-site VPN: in stap-foar-stap

De relay wurket yn trije skonken, en allinnich de middelste stekt de VPN oer. In klant stjoert in broadcast op it filiaalsegment, de ASA makket fan dy broadcast in unicast-oanfraach oan de DHCP-tsjinner, en de tsjinner antwurdet op it relayadres ynstee fan op de klant. Rin de skonken yn dy folchoarder troch, en de measte gefallen fan «de relay is stikken» komme del op in ûntbrekkend belied of in ferkeard lêzen rigel setroute.

Skonk ien: skeakelje relay yn op it klantrjochte ynterface

Op de ASA fan de filiaal is relay in eigenskip fan it ynterface dat nei de klanten sjocht. De tsjinner kin globaal ferklearre wurde mei syn berikbere ynterface, of ûnder dat klantrjochte ynterface sadat de routingtabel de útgong kiest. Dy twa foarmen binne net útwikselber, en de ferkearde kopiearje is it earste plak dêr't in paad misgiet.

Kontrolearje de rinnende konfiguraasje foar't jo eat feroarje: hokker ynterface relay ynskeakele hat, hokker tsjinnerfoarm oanwêzich is, en oft setroute oan it klantynterface ferbûn is. As de ASA ek in DHCP-tsjinner foar in oar segment draait, stopje dan en lês de beheiningslist; tsjinner en relay kinne net tagelyk op deselde masine ynskeakele wurde.

De relay set syn eigen klantrjochte adres yn it poarte-adresfjild. Dat adres is wat de tsjinner beantwurdzje sil, dus it moat fan it fiere plak ôf oer de tunnel berikber wêze, net allinnich lokaal.

Skonk twa: drage ASA-generearre ferkear oer de tunnel

Dit is de stap dy't minsken oerslaan. In beliedsbasearre site-to-site VPN wurdt meastentiids boud foar ferkear tusken subnetten, en de relayoanfraach wurdt troch de ASA sels generearre. As de tagongslist fan de tunnel en de kryptokaart allinnich oerienkomme mei streamen fan filiaalhost nei it subnet fan de tsjinner, dan komt it relaypakket miskien nea yn de tunnel. Kontrolearje de tagongslist yn beide rjochtingen, net allinnich de rigel fan filiaal nei tsjinner.

Befêstigje dat it nijsgjirrige ferkear de relayboarne fan de ASA en it adres fan de tsjinner dekt, en dat de weromrjochting ek tastien is. By in VTI-basearre ûntwerp is de routingbeslissing ienfâldiger, mar relaystipe oer VTI kaam yn in spesifike ferzje; de DHCP-gids fan de ASA neamt 9.14(1), dus kontrolearje de ôfbylding foar't jo in VTI-foarbyld nei in âlder apparaat kopiearje.

In ping fan de ASA nei de tsjinner bewiist op himsels net folle. Hy kin slagje fia in oar paad, mei in oar boarneadres, of ûnder in belied dêr't de pakketten fan de relay net oan foldogge.

Skonk trije: lês it antwurd en de setroute-opsje

RFC 2131 seit dat de tsjinner syn antwurd stjoert nei it adres yn giaddr as dat fjild net nul is. Dus moat it werompaad nei it relayadres route, en it tunnelbelied moat de rjochting fan tsjinner nei relay tastean. As de oanfraach trochkaam mar it oanbod nea oankomt, is dit it plak om te sykjen.

Skied dan twa dingen dy't itselde klinke. It kaaiwurd setroute feroaret of foeget de standertrouter-opsje ta dy't de ASA oan de klant jout. It ynstallearret gjin rûte op de ASA en makket gjin VPN-belied. In klant dy't in adres krijt mar neat berikt, hat faak in setroute- of berikprobleem, net in tunnelprobleem. Test it mei in klant sûnder statyske poarte en sjoch hokker standertrouter yn it oanbod ferskynt.

Lês it oanbod fan begjin oant ein: oanbean adres, masker, standertrouter, DNS en hiertiid. Lit de hier dan fernije. In relay dy't ien kear wurket en by fernijing mislearret, hat meastentiids in berik-, hier- of werompaadprobleem dat de earste útwiksel ferburgen hat.

Wat ik kontrolearje foar't ik it reparearre neam

Begjin by de klant en fêstlêzje de broadcast, befêstigje dan dat de ASA it trochstjoerd hat mei syn eigen adres as giaddr. Oan de fiere kant befêstigje dat de tsjinner dy oanfraach seach en in berik keas dat by de filiaal past. Werom yn de filiaal befêstigje dat de klant it oanbod akseptearre hat en syn poarte berikt.

As ien skonk stil is, kontrolearje dan it oerienkommende belied of de rûte ynstee fan noch in relayferklearring ta te foegjen. De relaykonfiguraasje is meastentiids al goed as immen eskaleart; it tunnelbelied of de weromrûte is wat feroare is.

Skriuw de trije skonken yn it feroaringsregister: klantrjochte ynterface, VPN-belied dat relayferkear dekt, en de weromrûte fan de tsjinner nei giaddr. Dat register makket de folgjende filiaalbou in werhelber wurk ynstee fan in debugsesje. It fertelt de folgjende yngenieur ek hokker kommando-útfier earst sammele wurde moat.