SSH etä-ASA:han sivuston VPN:n kautta: vaihe vaiheelta

Osoitat SSH-asiakkaan etä-ASA:n sisäiseen osoitteeseen ja istunto kuolee yhdistettäessä. Palomuuri vastaa omalta sivustoltaan, tunneli näkyy, eikä silti mikään kuuntele portissa 22. Useimmissa näistä tapauksista paketti ei koskaan saavuta hallinnan hyväksyntää, koska testattavaa polkua ei koskaan suunniteltu hallintapoluksi. Käy alla oleva kulku järjestyksessä läpi, niin vika lakkaa siirtymästä.

Valitse osoite, jota todella hallitset

Kolme ratkaisua näyttävät samanlaisilta ja käyttäytyvät eri tavoin: ASA:n julkisen VPN-osoitteen saavuttaminen, sisäisen rajapinnan saavuttaminen IPsecin kautta ja erillisen hallintarajapinnan saavuttaminen. Kirjoita ylös järjestelmänvalvojan lähdeosoite, tarkka kohdeosoite ja TCP 22 ennen kuin kosket lupaan. Kaikki myöhempi riippuu tästä parista.

Tunneli, joka kuljettaa kahta palvelin-VLANia, ei välttämättä kuljeta lainkaan palomuurin rajapintaosoitetta tai järjestelmänvalvojan hallinta-aliverkkoa. Tarkista sivusto-sivusto-käytännön kiinnostavan liikenteen luettelo ja varmista, että ASA:n oma osoite näkyy kohteena, eikä vain sen läpi kulkevat aliverkot.

Koska kohde on palomuuri itse, hallinnan hyväksyntä on erillään välitetyn liikenteen säännöistä. ACL, joka päästää asiakkaat ASA:n takana oleviin palvelimiin, ei itsestään ota käyttöön laitteen SSH-hallintaa, eikä välityssäännön korjaaminen siirrä tätä vikaa.

management-access on rajapintakohtainen

management-access-komento käskee ASA:ta hyväksymään hallintayhteydet nimettyyn rajapintaan, kun ne saapuvat VPN:n kautta. Se ei luo reittiä, se ei lisää SSH-lupaa, eikä se koske kaikkia rajapintoja kerralla. Jos kohderajapinta ei ole nimetty rajapinta, yhteys hylätään ennen todennusta.

Kaksi poissulkemista puree tässä. Vain hallintaan tarkoitetut rajapinnat ovat tämän mekanismin ulkopuolella, ja ASA 9.20:n hallintaopas huomauttaa, että oletusarvoinen CiscoSSH-pino ei tue rajapintojen välistä SSH:ta VPN:n yli, kun taas ASA SSH -pino tukee. Vahvista käytössä oleva pino käyttöönotetusta versiosta ennen kuin käytät aikaa reitteihin.

Neljä porttia ennen kirjautumiskehotetta

Asiakkaan ja käyttäjänimikehotteen välissä on neljä itsenäistä porttia: hallintaparin reitti- ja tunnelivastaavuus, rajapinnan ACL, joka sallii TCP 22 ASA:n osoitteeseen, järjestelmänvalvojan lähteen kattava ssh-lupa ja kyseisen käyttäjän AAA-todennus. Jokainen niistä voi pudottaa paketin kertomatta asiakkaalle, mikä portti sulkeutui.

Käytä packet-traceria nähdäksesi, mikä portti epäonnistuu ennen kuin muutat mitään: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Jäljitys nimeää ACL:n, NAT-vaiheen ja to-the-box-päätöksen, mikä yleensä riittää reititysongelman erottamiseen hyväksyntäongelmasta.

Kirjoita kapea lupa, älä leveää

Rajaa lupa hyväksyttyyn hallinnolliseen aliverkkoon ja rajapintaan, joka vastaanottaa tunnelin liikennettä: ssh 10.10.5.0 255.255.255.0 inside. Yhdistä se todennusmenetelmään kuten aaa authentication ssh console LOCAL ja nimettyyn paikalliseen tiliin sen sijaan, että avaat jokaisen lähteen ulkorajapinnassa.

Pidä rajapinnan ACL ja ssh-lupa yhdenmukaisina. Lupa aliverkolle, jonka ACL estää, epäonnistuu silti, ja ACL, joka sallii aliverkon ilman vastaavaa ssh-merkintää, epäonnistuu seuraavalla portilla. Molemmat lauseet kuvaavat samaa polkua eri kerroksista, joten tarkastele niitä yhdessä käynnissä olevassa kokoonpanossa.

Vahvista nimetyltä isännältä ja kavenna sitten uudelleen

Avaa uusi istunto nimetyltä hallintaisännältä sen sijaan, että käyttäisit työpöytääsi, ja vahvista ASA:lta, mitä lähdeosoitetta ja rajapintaa yhteys käytti. Tarkista aktiiviset istunnot ja käynnissä olevan kokoonpanon SSH-osio istunnon ollessa auki, sulje se sitten ja poista kaikki testausta varten lisäämäsi väliaikainen lupa. Jos istunto ilmestyy mutta putoaa heti kirjautumisen jälkeen, jäljellä oleva ongelma on valtuutus eikä tavoitettavuus. Kirjaa rajapinta ja lähde muutoslokkiin, jotta seuraava henkilö ei toista diagnoosia.

Pidä konsoli tai muu itsenäisesti hyväksytty palautuspolku saatavilla koko muutoksen ajan. Kun yksityinen polku toimii, varmista, että julkiset lähteet ja asiaankuulumattomat VPN-käyttäjät eivät saaneet samaa pääsyä, koska kaikille toimiva hallintapolku on eri ongelma kuin se, jolla aloitit.