Split-tunnel stelt een openbare host niet vrij van de NAT-regels van de ASA

Split-tunneling wordt meestal beschreven als een manier om bedrijfsverkeer binnen de tunnel te houden en de rest van het internet buiten de firewall. Beide helften van die beschrijving zijn op dezelfde manier onjuist. Split-tunneling is een routebeslissing van de client, en een routebeslissing zegt niets over wat er met het pakket gebeurt nadat het de headend bereikt.

Eén partnerservice op een openbaar adres, die erop staat het adres van je hoofdkantoor te zien, is genoeg om het verhaal onderuit te halen.

De mythe: split-tunnel haalt de firewall uit het pad

De overtuiging is dat elke bestemming buiten de privébereiken op de lokale internetverbinding blijft, zodat de firewall die nooit ziet en er nooit een regel voor nodig heeft. Dat geldt alleen zolang de bestemming niet in de tunnellijst staat. Op het moment dat een beheerder een openbare host aan de split-include-ACL toevoegt, stuurt de client dat verkeer de tunnel in, en de ASA moet het routeren, filteren en vertalen zoals elke andere ontsleutelde flow. Aan de client is niets veranderd behalve de bestemmingslijst.

De client werd geen router. Hij volgde het beleid dat je hem gaf.

Wat een split-include-route werkelijk doet

In een Cisco ASA-installatie voor externe toegang draagt het groepsbeleid split-tunnel-policy tunnelspecified en een split-tunnel-network-list die een standaard-ACL aanwijst. Elke permit-regel in die ACL is een bestemming die de client de tunnel in moet sturen, en al het andere blijft de lokale standaardroute gebruiken.

Eén host toevoegen is één regel, en dat is het enige deel van de wijziging dat de client kan zien: access-list RA-SPLIT standard permit host 203.0.113.20.

Verbind de client daarna opnieuw. Het beleid wordt bij het verbinden uitgewisseld, dus een bestaande sessie houdt de oude lijst en laat de wijziging lijken alsof die niets deed.

Het pakket komt binnen en gaat weg op dezelfde interface

Volg nu de flow na het ontsleutelen. Het pakket kwam via de VPN-tunnel binnen op de buiteninterface, de bestemming is een openbaar adres, en de routetabel stuurt het via dezelfde buiteninterface terug richting internet. Verkeer dat op één interface binnenkomt en weggaat, wordt weggegooid tenzij de ASA het mag toestaan, en dat is wat same-security-traffic permit intra-interface doet. Zonder dat faalt de verbinding op een manier die op een routingprobleem lijkt en het niet is.

Die instelling is globaal. Ze staat hairpinning toe voor elke flow die het nodig heeft, niet alleen voor deze partnerhost, dus ze hoort in een beoordeelde wijziging en niet in een snelle test.

Waarom een tot de bestemming beperkte PAT niet optioneel is

Het bronadres op het ontsleutelde pakket is nog steeds het VPN-adres van de client, meestal uit een pool zoals 10.77.0.0/24. Dat adres heeft geen route op het openbare internet, dus de partner antwoordt of nooit of in het niets.

De vertaling corrigeert de bron en laat de bestemming ongemoeid. Omdat de objecten elders al zijn gedefinieerd, heeft een handmatige regel die tot deze bestemming is beperkt deze vorm:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

Het deel destination static is belangrijk. Laat je het weg, dan wordt de regel een brede vertaling die op veel meer verkeer kan passen dan bedoeld, en een brede identity-regel eerder in de volgorde kan deze volledig verslaan. Controleer show nat detail en de volgorde van de secties voordat je aanneemt dat jouw regel degene is die past.

Interface-PAT betekent ook dat de partner het interfaceadres van de ASA ziet, dat verder stroomopwaarts opnieuw kan worden vertaald. Als het contract een adres noemt, bevestig het dan van begin tot eind in plaats van bij één hop.

Bewijs het met de juiste testbestemming

Gebruik de partnerhost zelf, niet een generieke what-is-my-ip-pagina. Die pagina staat vrijwel zeker buiten de split-lijst, dus ze meldt je lokale internetadres en zegt niets over dit pad. Open een nieuwe verbinding naar de partnerservice en vraag welke bron zij hebben waargenomen, of voer packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed uit en lees de NAT- en routestappen regel voor regel. Een traceroute vanaf de client is een zwakkere controle, omdat die het pad toont dat al heeft plaatsgevonden en niet het beleid dat het koos.

Controleer daarna wat niet mag veranderen. Een gewone website moet nog steeds via de lokale verbinding naar buiten gaan, en een privébron in de tunnellijst moet nog steeds bereikbaar zijn. Een wijziging die de partner repareert en een van die twee breekt, is een andere bug.

De werkende versie van dit ontwerp is kort: één host in de split-ACL, hairpin-toestemming, één tot de bestemming beperkte PAT-regel. Al het andere in het verhaal is de mythe.