SSH kaugemale ASA-le saidi VPN-i kaudu: samm sammult

Suunate SSH-kliendi kaugema ASA sisemisele aadressile ja seanss sureb ühendamisel. Tulemüür vastab oma saidilt, tunnel ilmub, ja ometi ei kuula port 22 midagi. Enamikul neist juhtudest ei jõua pakett kunagi halduslubadeni, sest testitavat teed ei projekteeritud kunagi haldusteena. Käige allolev voog järjekorras läbi ja rike lakkab liikumast.

Valige aadress, mida te tegelikult haldete

Kolm lahendust näevad sarnased välja ja käituvad erinevalt: ASA avaliku VPN-aadressi saavutamine, sisemise liidese saavutamine IPsec kaudu ja eraldi haldusliidese saavutamine. Kirjutage üles administraatori lähteaadress, täpne sihtaadress ja TCP 22 enne, kui puudutate luba. Kõik hilisem sõltub sellest paarist.

Tunnel, mis kannab kahte serveri VLAN-i, ei pruugi üldse kanda tulemüüri liidese aadressi ega administraatori haldusalavõrku. Kontrollige saidi-saiti poliitika huvitava liikluse loendit ja kinnitage, et ASA enda aadress ilmub sihtkohana, mitte ainult alamvõrgud, mis sellest läbi lähevad.

Kuna sihtkoht on tulemüür ise, on haldusluba edasisaadetava liikluse reeglitest eraldi. ACL, mis laseb klientidel jõuda ASA taga olevate serveriteni, ei võimalda iseseisvalt seadme SSH-haldust, ja edasisaatmise reegli parandamine ei liiguta seda riket.

management-access on liidesepõhine

Käsk management-access ütleb ASA-le, et see võtaks vastu haldusühendusi nimetatud liidesele, kui need saabuvad VPN-i kaudu. See ei loo marsruuti, ei lisa SSH-luba ega kehti kõikidele liidestele korraga. Kui sihtliides ei ole nimetatud liides, visatakse ühendus enne autentimist ära.

Siin hammustavad kaks erandit. Ainult halduseks mõeldud liidesed on sellest mehhanismist väljas, ja ASA 9.20 haldusjuhend märgib, et vaikimisi CiscoSSH-pinu ei toeta liidestevahelist SSH-d VPN-i kaudu, samas kui ASA SSH pinu toetab. Kinnitage juurutatud väljalaske aktiivne pinu enne, kui kulutate aega marsruutidele.

Neli väravat enne sisselogimiskutset

Kliendi ja kasutajanimekutse vahel seisab neli sõltumatut väravat: halduspaari marsruudi ja tunneli vastavus, liidese ACL, mis lubab TCP 22 ASA aadressile, administraatori lähteet kattev ssh-luba ja selle kasutaja AAA-autentimine. Igaüks neist võib paketi maha visata, ütlemata kliendile, milline värav sulgus.

Kasutage packet-tracerit, et näha, milline värav ebaõnnestub, enne kui midagi muudate: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Jälg nimetab ACL-i, NAT-i etapi ja to-the-box otsuse, millest tavaliselt piisab marsruutimisprobleemi eraldamiseks lubamisprobleemist.

Kirjutage kitsas luba, mitte lai

Piirake luba kinnitatud haldusalavõrgu ja tunneliliiklust vastuvõtva liidesega: ssh 10.10.5.0 255.255.255.0 inside. Siduge see autentimismeetodiga nagu aaa authentication ssh console LOCAL ja nimetatud kohaliku kontoga, selle asemel et avada välisliidesel iga allikas.

Hoidke liidese ACL ja ssh-luba kooskõlas. Luba alamvõrgule, mille ACL blokeerib, ebaõnnestub ikkagi, ja ACL, mis lubab alamvõrku ilma vastava ssh-kirjeta, ebaõnnestub järgmisel väraval. Mõlemad väited kirjeldavad sama teed erinevatest kihtidest, seega vaadake need töötavas konfiguratsioonis koos üle.

Kontrollige nimetatud hostist ja kitsendage seejärel uuesti

Avage uus seanss nimetatud haldushostist, mitte oma töölaualt, ja kinnitage ASA-l, millist lähteaadressi ja liidest ühendus kasutas. Kontrollige aktiivseid seansse ja töötava konfiguratsiooni SSH-osa, kui seanss on avatud, sulgege see seejärel ja eemaldage kõik testimiseks lisatud ajutine luba. Kui seanss ilmub, kuid langeb kohe pärast sisselogimist, on allesjäänud probleem autoriseerimine, mitte kättesaadavus. Kirjutage liides ja allikas muudatuste logisse, et järgmine inimene diagnoosi ei kordaks.

Hoidke konsool või muu sõltumatult kinnitatud taastetee kogu muudatuse ajal saadaval. Kui privaatne tee töötab, kinnitage, et avalikud allikad ja mitteseotud VPN-kasutajad ei saanud sama juurdepääsu, sest kõigile töötav haldustee on teine probleem kui see, millega alustasite.