SSH drejt një ASA të largët përmes VPN-së së sajtit: hap pas hapi

Drejtoni një klient SSH drejt adresës së brendshme të ASA-së së largët dhe sesioni vdes gjatë lidhjes. Muri i zjarrit përgjigjet nga sajti i vet, tuneli shfaqet, dhe megjithatë asgjë nuk dëgjon në portën 22. Në shumicën e këtyre rasteve paketa nuk arrin kurrë në pranimin e administrimit, sepse rruga që testoni nuk është projektuar kurrë si rrugë administrimi. Ndiqni rrjedhën më poshtë sipas radhës dhe defekti ndalon së zhvendosuri.

Zgjidhni adresën që po administroni vërtet

Tre modele duken njësoj dhe sillen ndryshe: arritja e adresës publike të ASA-së të kthyer drejt VPN-së, arritja e një ndërfaqeje të brendshme përmes IPsec dhe arritja e një ndërfaqeje të dedikuar administrimi. Shkruani adresën burimore të administratorit, adresën e saktë të destinacionit dhe TCP 22 përpara se të prekni ndonjë leje. Gjithçka më pas varet nga ai çift.

Një tunel që mbart dy VLAN serverësh mund të mos mbartë fare adresën e ndërfaqes së murit të zjarrit ose nënrrjetin e administrimit të administratorit. Kontrolloni listën e trafikut interesant për politikën sajt-në-sajt dhe konfirmoni që adresa e vetë ASA-së shfaqet si destinacion, jo vetëm nënrrjetet që kalojnë përmes tij.

Meqenëse destinacioni është vetë muri i zjarrit, pranimi i administrimit është i ndarë nga rregullat për trafikun e përcjellë. Një ACL që lejon klientët të arrijnë serverët prapa ASA-së nuk aktivizon vetvetiu administrimin SSH të pajisjes, dhe rregullimi i rregullit të përcjelljes nuk do ta zhvendosë këtë defekt.

management-access është specifik për ndërfaqen

Komanda management-access i thotë ASA-së të pranojë lidhje administrimi drejt një ndërfaqeje të emërtuar kur ato vijnë përmes VPN-së. Nuk krijon një rrugë, nuk shton një leje SSH dhe nuk zbatohet për çdo ndërfaqe njëkohësisht. Nëse ndërfaqja e destinacionit nuk është ajo e emërtuara, lidhja hidhet poshtë përpara vërtetimit.

Këtu kafshojnë dy përjashtime. Ndërfaqet vetëm për administrim janë jashtë këtij mekanizmi, dhe udhëzuesi i administrimit të ASA 9.20 vëren se stiva standarde CiscoSSH nuk mbështet SSH midis ndërfaqeve përmes VPN-së, ndërsa stiva ASA SSH e mbështet. Konfirmoni stivën aktive në versionin e vendosur përpara se të shpenzoni kohë me rrugët.

Katër porta përpara kërkesës për hyrje

Midis klientit dhe kërkesës për emrin e përdoruesit qëndrojnë katër porta të pavarura: përputhja e rrugës dhe e tunelit për çiftin e administrimit, një ACL ndërfaqeje që lejon TCP 22 drejt adresës së ASA-së, një leje ssh që mbulon burimin e administratorit dhe një vërtetim AAA për atë përdorues. Secila prej tyre mund ta hedhë paketën pa i thënë klientit cila portë u mbyll.

Përdorni packet-tracer për të parë cila portë dështon përpara se të ndryshoni çdo gjë: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Gjurma emërton ACL-në, fazën NAT dhe vendimin to-the-box, që zakonisht mjafton për të ndarë një problem rrugëtimi nga një problem pranimi.

Shkruani lejen e ngushtë, jo atë të gjerë

Kufizoni lejen në nënrrjetin administrativ të miratuar dhe në ndërfaqen që merr trafikun e tunelit: ssh 10.10.5.0 255.255.255.0 inside. Çiftojeni me një metodë vërtetimi si aaa authentication ssh console LOCAL dhe një llogari lokale të emërtuar, në vend që të hapni çdo burim në ndërfaqen e jashtme.

Mbani ACL-në e ndërfaqes dhe lejen ssh në përputhje. Një leje për një nënrrjet që ACL-ja bllokon dështon gjithsesi, dhe një ACL që lejon nënrrjetin pa një zë ssh përkatës dështon në portën tjetër. Të dyja pohimet përshkruajnë të njëjtën rrugë nga shtresa të ndryshme, prandaj rishikojini së bashku në konfigurimin që po ekzekutohet.

Verifikoni nga hosti i emërtuar, pastaj ngushtoni përsëri

Hapni një sesion të re nga hosti i administrimit i emërtuar dhe jo nga tavolina juaj, dhe konfirmoni në ASA cila adresë burimore dhe cila ndërfaqe u përdor nga lidhja. Kontrolloni sesionet aktive dhe seksionin SSH të konfigurimit që po ekzekutohet ndërsa sesioni është i hapur, pastaj mbylleni dhe hiqni çdo leje të përkohshme që keni shtuar për testim. Nëse sesioni shfaqet por bie menjëherë pas hyrjes, problemi i mbetur është autorizimi dhe jo arritshmëria. Regjistroni ndërfaqen dhe burimin në regjistrin e ndryshimeve, që personi tjetër të mos e përsërisë diagnostikimin.

Mbani konsolën ose një rrugë tjetër rikuperimi të miratuar në mënyrë të pavarur të disponueshme gjatë gjithë ndryshimit. Pasi rruga private të funksionojë, konfirmoni që burimet publike dhe përdoruesit e VPN-së të palidhur nuk kanë marrë të njëjtin akses, sepse një rrugë administrimi që funksionon për të gjithë është një problem tjetër nga ai me të cilin filluat.