Welk pakket moet een VPN-beleid met twee WAN's matchen?

Verzoeken om de VPN via de tweede uplink te routeren beschrijven minstens twee verschillende taken, en het beleid dat de ene oplost, raakt de andere niet. In de eerste taak verhuist het versleutelde transport tussen twee eindpunten naar een ander WAN-adres. In de tweede verlaat de ontsleutelde applicatiestroom van een verbonden gebruiker het apparaat richting een andere volgende hop. Beide zijn legitiem, beide gebruiken routering, en elk vereist een match op een pakket dat bestaat op het punt waar de beslissing valt. Loop de controles hieronder in volgorde door, want de eerste bepaalt welk pakket latere regels moeten benoemen.

Benoem de twee gesprekken

Stel u een externe medewerker voor die aan een kantoor-gateway hangt en HTTPS opent naar een interne applicatieserver. Er staan twee onafhankelijke gesprekken op de lijn, en ze hebben aan elk uiteinde andere adressen. Het buitenste gesprek loopt tussen de twee VPN-eindpunten: van gatewayadres naar peeradres, in welk protocol en welke poort de uitrol ook heeft onderhandeld. Het binnenste gesprek loopt van het adres dat de client kreeg naar het adres van de applicatieserver op poort 443.

De bestemmingspoort van de applicatie is niet de transportpoort van de VPN, en geen enkele hoeveelheid beleid op TCP 443 verplaatst de tunnel. Evenzo zegt een regel die het transportadres van de peer omleidt niets over waar de HTTP-aanvraag van die gebruiker na ontsleuteling heen gaat. Schrijf beide gesprekken met hun echte adressen op voordat u een regel aanraakt, want de meeste verwarring op dit gebied komt voort uit het benoemen van de een en het configureren van de ander.

Ontdek waar uw beleid het pakket werkelijk kan zien

De match moet worden geëvalueerd in de keten en de namespace waar het pakket nog de vorm heeft die u beschreef. Een regel die aan LAN-ingress hangt, ziet het binnenste pakket onversleuteld, voordat het naar de tunnel wordt gerouteerd. Een regel die op lokaal gegenereerd verkeer wordt toegepast, ziet pakketten die de gateway zelf maakt, en die dekt niet automatisch verkeer dat de gateway alleen doorstuurt. Ingekapselde uitvoer is weer een derde geval, meestal afgehandeld op de interface die de tunnel draagt en niet aan de LAN-zijde.

Daarom gedraagt hetzelfde configuratiefragment zich anders op twee platformen: de aanhechtpunten verschillen, en de beleidshook van een leverancier kan voor of na de versleutelingsstap zitten. Lees het pakketpad voor het specifieke product in plaats van de volgorde aan te nemen uit het diagram van een andere leverancier.

Bevestig het transport dat u hebt onderhandeld

Voor UDP-ingekapselde IPsec plaatst RFC 3948 ESP in UDP en gebruikt een markering die geen ESP is om IKE onderscheidbaar te houden op de gedeelde poort. Gewone ESP is een IP-protocol, geen TCP- of UDP-poort, dus een firewallregel die op een poortnummer is geschreven, matcht het helemaal niet. Dit onderscheid bepaalt of uw WAN-beleid een UDP-regel, een protocolregel of beide nodig heeft.

Onderhandelde waarden verslaan onthouden waarden. Lees de huidige poorten en adressen van de associatie van het apparaat af in plaats van TCP 4500 of een oude leverancierspoort voor de zekerheid toe te voegen, wat ongerelateerd verkeer opvangt en het echte classificatieprobleem verbergt.

Controleer de retourweg voordat u zich vastlegt

Succes naar buiten bewijst de helft van een ontwerp. Een pakket dat terugkeert naar de pool van externe clients is niet langer zichtbaar onder het adres van de client zodra de inkapseling die vervangt: de buitenste bestemming is het transportadres van de peer. Als de tweede uplink die peer via een andere provider bereikt, kunnen de vertaling en filtering ervan afwijken van de eerste, en moet de associatie mogelijk opnieuw worden opgebouwd in plaats van gemigreerd.

De toestand van netwerkadresvertaling is het gebruikelijke slachtoffer van een WAN-wissel. Noteer de gekozen uplink, het verwachte buitenste bronadres, de gebruikte vertaling en de bereikbaarheid van de peer terug, en houd het transport daarna bereikbaar zonder het in de tunnel te sturen die het draagt.

Verifieer beide lagen met twee opnamen

Eén opname op de WAN-interface en één in de tunnel beslechten de vraag sneller dan welke configuratievergelijking dan ook. Voer ze uit vanaf de gateway terwijl een goedgekeurde client één verzoek doet, en bewaar beide bestanden.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

De eerste opname zou het buitenste gesprek moeten tonen dat de interface verlaat die u bedoelde, met het verwachte bronadres. De tweede zou het binnenste gesprek één keer moeten tonen, niet gedupliceerd, met het clientadres als bron en de applicatieserver als bestemming. De route-opzoeking bevestigt welke tabel de router voor dat bron-bestemming-paar zou gebruiken, en daar duikt een beleidsfout meestal op. Als een van de opnamen niet verschijnt, ligt het beslispunt ergens anders dan waar de regel is aangehecht, en de correctie hoort daar en niet in een bredere match.