ASA:n DHCP-relay site-to-site-VPN:n yli: vaihe vaiheelta

Relay toimii kolmessa vaiheessa, ja vain keskimmäinen ylittää VPN:n. Asiakas lähettää yleislähetyksen haarakonttorin segmentissä, ASA muuttaa sen unicast-pyynnöksi DHCP-palvelimelle, ja palvelin vastaa relay-osoitteeseen eikä asiakkaaseen. Käy vaiheet läpi tässä järjestyksessä, ja useimmat tapaukset «relay on rikki» ratkeavat puuttuvaksi käytännöksi tai väärin luetuksi riviksi setroute.

Vaihe yksi: ota relay käyttöön asiakkaaseen päin olevalla rajapinnalla

Haarakonttorin ASA:ssa relay on sen rajapinnan ominaisuus, joka osoittaa asiakkaisiin. Palvelin voidaan määritellä globaalisti sen tavoitettavissa olevalla rajapinnalla tai kyseisen asiakasrajapinnan alle, jotta reititystaulu valitsee ulostulon. Nämä kaksi muotoa eivät ole vaihdettavissa, ja väärän kopioiminen on ensimmäinen kohta, jossa opas menee pieleen.

Tarkista käynnissä oleva kokoonpano ennen kuin muutat mitään: millä rajapinnalla relay on käytössä, mikä palvelinmuoto on läsnä ja onko setroute liitetty asiakasrajapintaan. Jos ASA ajaa myös DHCP-palvelinta toiselle segmentille, pysähdy ja lue rajoitusluettelo; palvelinta ja relaytä ei voi ottaa käyttöön samanaikaisesti samassa laitteessa.

Relay asettaa oman asiakkaaseen päin olevan osoitteensa yhdyskäytäväosoitteen kenttään. Juuri tähän osoitteeseen palvelin vastaa, joten sen on oltava tavoitettavissa etäsivustolta tunnelin kautta, ei vain paikallisesti.

Vaihe kaksi: kuljeta ASA:n tuottama liikenne tunnelin läpi

Tämä on vaihe, jonka ihmiset ohittavat. Käytäntöpohjainen site-to-site-VPN rakennetaan yleensä aliverkkojen väliselle liikenteelle, ja relay-pyynnön tuottaa ASA itse. Jos tunnelin access-lista ja crypto-kartta vastaavat vain haarakonttorin isännältä palvelimen aliverkkoon meneviä virtoja, relay-paketti ei välttämättä koskaan päädy tunneliin. Tarkista access-lista molempiin suuntiin, ei vain riviä haarakonttorista palvelimelle.

Varmista, että kiinnostava liikenne kattaa ASA:n relay-lähteen ja palvelimen osoitteen ja että myös paluusuunta on sallittu. VTI-pohjaisessa suunnittelussa reitityspäätös on yksinkertaisempi, mutta relay-tuki VTI:n yli tuli tietyssä julkaisussa; ASA:n DHCP-opas mainitsee version 9.14(1), joten tarkista kuva ennen kuin kopioit VTI-esimerkin vanhempaan laitteeseen.

Ping ASA:sta palvelimelle todistaa itsessään vähän. Se voi onnistua toista reittiä, toisella lähdeosoitteella tai käytännön alla, jota relayn paketit eivät vastaa.

Vaihe kolme: lue vastaus ja setroute-vaihtoehto

RFC 2131 sanoo, että palvelin lähettää vastauksensa osoitteeseen kentässä giaddr, kun kenttä ei ole nolla. Siis paluureitin on reitityttävä relay-osoitteeseen, ja tunnelikäytännön on sallittava suunta palvelimesta relayhin. Jos pyyntö meni läpi mutta tarjous ei koskaan saavu, tästä kannattaa katsoa.

Erottele sitten kaksi samalta kuulostavaa asiaa. Avainsana setroute muuttaa tai lisää oletusreitittimen vaihtoehdon, jonka ASA antaa asiakkaalle. Se ei asenna reittiä ASA:han eikä luo VPN-käytäntöä. Asiakas, joka saa osoitteen mutta ei tavoita mitään, kärsii usein setroute- tai laajuusongelmasta, ei tunneliongelmasta. Testaa asiakkaalla, jolla ei ole staattista yhdyskäytävää, ja katso mikä oletusreititin tarjouksessa näkyy.

Lue tarjous alusta loppuun: tarjottu osoite, maski, oletusreititin, DNS ja vuokra-aika. Anna sitten vuokran uusiutua. Relay, joka toimii kerran ja epäonnistuu uusinnassa, kärsii yleensä laajuus-, vuokra- tai paluureittiongelmasta, jonka ensimmäinen vaihto peitti.

Mitä tarkistan ennen kuin sanon sen olevan kunnossa

Aloita asiakkaasta ja kaappaa yleislähetys, varmista sitten, että ASA välitti sen omalla osoitteellaan giaddr-arvona. Etäpäässä varmista, että palvelin näki pyynnön ja valitsi haarakonttoriin sopivan laajuuden. Takaisin haarakonttorissa varmista, että asiakas hyväksyi tarjouksen ja tavoittaa yhdyskäytävänsä.

Jos jokin vaihe on äänetön, tarkista vastaava käytäntö tai reitti sen sijaan, että lisäisit uuden relay-lauseen. Relay-kokoonpano on yleensä oikein siihen mennessä, kun joku eskaloi; muuttunut asia on tunnelikäytäntö tai paluureitti.

Kirjaa kolme vaihetta muutosmerkintään: asiakasrajapinta, relay-liikenteen kattava VPN-käytäntö ja palvelimen paluureitti osoitteeseen giaddr. Juuri tämä merkintä tekee seuraavasta haarakonttorin rakennuksesta toistettavan työn eikä virheenkorjausistunnon. Se myös kertoo seuraavalle insinöörille, mikä komentotuloste kerätään ensin.