Vilket paket måste en VPN-policy med två WAN matcha?

Förfrågningar om att routa VPN över den andra upplänken beskriver minst två olika jobb, och policyn som löser det ena rör inte det andra. I det första jobbet flyttar den krypterade transporten mellan två ändpunkter till en annan WAN-adress. I det andra lämnar en ansluten användares dekrypterade applikationsflöde mot ett annat nästa hopp. Båda är legitima, båda använder routning, och var och en kräver en matchning på ett paket som finns vid den punkt där beslutet fattas. Gå igenom kontrollerna nedan i ordning, eftersom den första avgör vilket paket senare regler måste namnge.

Namnge de två samtalen

Föreställ dig en distansarbetare ansluten till en kontorsgateway, som öppnar HTTPS mot en intern applikationsserver. Det finns två oberoende samtal på ledningen, och de har olika adresser i varje ände. Det yttre samtalet går mellan de två VPN-ändpunkterna: gatewayadress till peeradress, med det protokoll och den port som driftsättningen förhandlade fram. Det inre samtalet går från adressen klienten tilldelades till applikationsserverns adress på port 443.

Applikationens destinationsport är inte VPN:s transportport, och ingen mängd policy på TCP 443 flyttar tunneln. På samma sätt säger en regel som omdirigerar peerns transportadress ingenting om vart den användarens HTTP-begäran tar vägen efter dekryptering. Skriv ned båda samtalen med sina verkliga adresser innan du rör en regel, eftersom det mesta av förvirringen på det här området kommer av att namnge den ena och konfigurera den andra.

Ta reda på var din policy faktiskt kan se paketet

Matchningen måste utvärderas i den kedja och den namnrymd där paketet fortfarande har den form du beskrev. En regel fäst vid LAN-ingress ser det inre paketet okrypterat, innan det routas mot tunneln. En regel som tillämpas på lokalt genererad trafik ser paket som gatewayen själv skapar, och den täcker inte automatiskt trafik som gatewayen bara vidarebefordrar. Inkapslad utgång är återigen ett tredje fall, vanligtvis hanterat på det gränssnitt som bär tunneln och inte på LAN-sidan.

Det är därför samma konfigurationsutdrag beter sig olika på två plattformar: fästpunkterna skiljer sig, och en leverantörs policykrok kan sitta före eller efter krypteringssteget. Läs paketvägen för den specifika produkten i stället för att anta ordningen från en annan leverantörs diagram.

Bekräfta transporten du förhandlade fram

För UDP-inkapslad IPsec placerar RFC 3948 ESP inuti UDP och använder en markör som inte är ESP så att IKE förblir urskiljbar på den delade porten. Vanlig ESP är ett IP-protokoll, inte en TCP- eller UDP-port, så en brandväggsregel skriven mot ett portnummer matchar den inte alls. Den här skillnaden avgör om din WAN-policy behöver en UDP-regel, en protokollregel eller båda.

Förhandlade värden slår ihågkomna. Läs associationens aktuella portar och adresser från enheten i stället för att lägga till TCP 4500 eller en gammal leverantörsport för säkerhets skull, vilket fångar orelaterad trafik och döljer det egentliga klassificeringsproblemet.

Kontrollera returvägen innan du binder dig

Framgång utåt bevisar halva en design. Ett paket som återvänder mot poolen av fjärrklienter syns inte längre under klientens adress när inkapslingen ersätter den: den yttre destinationen är peerns transportadress. Om den andra upplänken når den peeren via en annan operatör kan dess översättning och filtrering inte stämma med den första, och associationen kan behöva byggas om i stället för att migreras.

Tillståndet för nätverksadressöversättning är det vanliga offret för ett WAN-byte. Notera den valda upplänken, den förväntade yttre källadressen, översättningen som används och peerns nåbarhet tillbaka till den, och håll sedan transporten nåbar utan att skicka in den i tunneln den bär.

Verifiera båda lagren med två avlyssningar

En avlyssning på WAN-gränssnittet och en inne i tunneln avgör frågan snabbare än någon konfigurationsdiff. Kör dem från gatewayen medan en godkänd klient utför en enda begäran, och spara båda filerna.

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

Den första avlyssningen bör visa det yttre samtalet lämna det gränssnitt du avsåg, med den förväntade källadressen. Den andra bör visa det inre samtalet en gång, inte duplicerat, med klientadressen som källa och applikationsservern som destination. Ruteuppslaget bekräftar vilken tabell routern skulle använda för det käll- och destinationsparet, och det är där ett policyfel brukar dyka upp. Om någon av avlyssningarna inte dyker upp ligger beslutspunkten någon annanstans än där regeln fästes, och rättelsen hör hemma där och inte i en bredare matchning.