Udgivelse af en intern tjeneste over en ASA site-to-site-VPN

At udgive en tjeneste, der lever bag en site-to-site-VPN, er én opgave med fem fejlpunkter, og de fejler i en fast rækkefølge. Tunnelen kommer op, oversættelsen passer, filialen svarer, og svaret kommer tilbage ad samme vej. Når blot ét af dem er forkert, viser browseren det samme: en forbindelse, der hænger eller nulstilles. Arbejd listen oppefra og ned, og stop ved den første kontrol, der fejler.

Kontrol 1: tunnelen beskytter oprindelsesadressen

Start med en tunnel, der allerede fører trafik, og bekræft derefter, at den adresse, du planlægger at udgive, ligger inden for det beskyttede interval. På en ASA kommer det interval fra krypto-ACL’en eller fra ruterne i en VTI, og det skal dække oprindelsens rigtige adresse frem for det undernet, filialen bruger til administration. En selector, der rammer forbi oprindelsen, giver dig en tunnel, der er oppe, og en flow, der aldrig går ind i den.

Bekræft det med tunnel-tællerne og rutetabellen, før du rører oversættelsen. Hvis oprindelsen ikke kan nås fra hub’en gennem tunnelen, kan intet senere på denne liste reparere det.

Stop her, hvis det beskyttede interval og oprindelsesadressen ikke stemmer overens.

Kontrol 2: beslut, hvilken kilde filialen ser

Filialen ser enten den oprindelige klientadresse eller en oversat, og det valg afgør returvejen. At bevare klientadressen læser renere i oprindelsens logfiler, men så skal filialen sende svar for offentlige klienter tilbage gennem tunnelen; en almindelig internet-default sender dem den anden vej, og forbindelsen dør i én retning. At oversætte kilden til en adresse, som filialen allerede ruter over tunnelen, fjerner det krav.

Oversættelse ændrer også, hvad oprindelsen kan logge, og hvad kildestyrede regler kan matche. Hvis applikationen skal kende mennesket bag en anmodning, hører det hjemme i en autentificeret omvendt proxy, ikke i en NAT-beslutning.

Kontrol 3: skriv oversættelsen mod de rigtige grænseflader

En ASA evaluerer oversættelsesregler i rækkefølge og rapporterer, hvilken der matchede, så grænsefladeparret i reglen er ikke kosmetisk. En regel skrevet til en vej udefra og ind matcher ikke en flow, hvis indgang og udgang afviger fra dem, du antog.

Den vej, du bygger, har fire ben, og alle fire skal stemme:

Behandl intervallerne i den tabel som pladsholdere. Det afgørende er, at tuplen efter oversættelse er en adresse, filialen accepterer over tunnelen, og at den omvendte mapping findes i NAT-tilstanden, så svaret gendannes på vejen ud.

Kontrol 4: begræns adgangsreglen til den udgivne port

Udgiv porten, ikke værten. En regel, der tillader oprindelsen på hver tjeneste, gør én udgivet applikation til en vej til alt, hvad oprindelsen kører, inklusive det administrationsgrænseflade, du med vilje holdt uden for internettet. Tillad den udgivne port fra den oversatte kilde til oprindelsen, og lad administrative tjenester blive på deres VPN-only-vej.

Kontroller regelrækkefølgen samtidig. En bred tilladelse, der ligger over din specifikke regel, gør den specifikke regel usynlig.

Kontrol 5: spor én anmodning og dens svar

Start ikke med en browser, for en browser skjuler, hvilket ben der fejlede. Spor flowet på hub’en, og læs resultatet, før du ændrer noget.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

Sporingen navngiver den oversættelse, der matchede, den adgangsregel, der tillod eller afviste flowet, og om pakken blev rutet ind i tunnelen. Hvis den viser flowet forlade en grænseflade, du ikke forventede, er grænsefladeparret i NAT-reglen forkert. Hvis den viser en afvisning, er regelrækkefølgen forkert. Hvis den når tunnelen, men oprindelsen aldrig svarer, er filialens returvej problemet.

Send derefter én rigtig anmodning udefra, og bekræft, at svaret kommer tilbage gennem samme tunnel. Notér den udgivne post, oversættelsen, det beskyttede adressepar og returruten som udgivelsesrekorden.