Publicera en intern tjänst över en ASA site-to-site-VPN

Att publicera en tjänst som lever bakom en site-to-site-VPN är en uppgift med fem felpunkter, och de fallerar i fast ordning. Tunneln kommer upp, översättningen stämmer, filialen svarar och svaret kommer tillbaka samma väg. När något av detta är fel visar webbläsaren samma sak: en anslutning som hänger eller återställs. Arbeta igenom listan uppifrån och ned och stanna vid den första kontrollen som fallerar.

Kontroll 1: tunneln skyddar källadressen

Börja med en tunnel som redan för trafik och bekräfta sedan att adressen du planerar att publicera ligger inom det skyddade området. På en ASA kommer området från krypto-ACL:en eller från rutterna i en VTI, och det måste täcka källans verkliga adress, inte subnätet filialen använder för administration. En väljare som missar källan ger dig en tunnel som står och ett flöde som aldrig kommer in i den.

Bekräfta det med tunnelräknarna och routingtabellen innan du rör översättningen. Om källan inte nås från hubben genom tunneln kan inget längre ned i listan reparera det.

Stanna här om det skyddade området och källadressen inte stämmer överens.

Kontroll 2: bestäm vilken källa filialen ser

Filialen ser antingen klientens ursprungliga adress eller en översatt, och det valet avgör returvägen. Att bevara klientadressen läses renare i källans loggar, men då måste filialen skicka svar för offentliga klienter tillbaka genom tunneln; en vanlig standardväg ut på internet skickar dem åt andra hållet och anslutningen dör i en riktning. Att översätta källan till en adress som filialen redan routar över tunneln tar bort det kravet.

Översättning ändrar också vad källan kan logga och vad källbaserade regler kan matcha. Om applikationen behöver känna till människan bakom en begäran hör det hemma i en autentiserad omvänd proxy, inte i ett NAT-beslut.

Kontroll 3: skriv översättningen mot de verkliga gränssnitten

En ASA utvärderar översättningsregler i ordning och rapporterar vilken som matchade, så gränssnittsparet i regeln är inte kosmetiskt. En regel skriven för en väg utifrån och in matchar inte ett flöde vars ingång och utgång avviker från dem du antog.

Vägen du bygger har fyra delar, och alla fyra måste stämma:

Behandla områdena i tabellen som platshållare. Det som spelar roll är att tupeln efter översättning är en adress som filialen accepterar över tunneln, och att den omvända mappningen finns i NAT-tillståndet så att svaret återställs på väg ut.

Kontroll 4: begränsa åtkomstregeln till den publicerade porten

Publicera porten, inte värden. En regel som tillåter källan på varje tjänst gör en publicerad applikation till en väg till allt källan kör, inklusive administrationsgränssnittet du med avsikt höll utanför internet. Tillåt den publicerade porten från den översatta källan till källan och låt administrativa tjänster ligga kvar på sin enbart-VPN-väg.

Kontrollera regelordningen samtidigt. En bred tillåtelse ovanför din specifika regel gör den specifika regeln osynlig.

Kontroll 5: spåra en begäran och dess svar

Börja inte med en webbläsare, eftersom en webbläsare döljer vilken del som fallerade. Spåra flödet på hubben och läs resultatet innan du ändrar något.

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

Spårningen namnger översättningen som matchade, åtkomstregeln som tillät eller nekade flödet och om paketet routades in i tunneln. Om den visar flödet lämna ett gränssnitt du inte väntade dig är gränssnittsparet i NAT-regeln fel. Om den visar en nekad begäran är regelordningen fel. Om den når tunneln men källan aldrig svarar är problemet filialens returväg.

Skicka sedan en riktig begäran utifrån och bekräfta att svaret kommer tillbaka genom samma tunnel. Notera den publicerade posten, översättningen, det skyddade adressparet och returvägen som publiceringsposten.