Utökning av webbplatsens VPN: följ returvägen förbi gatewayen

Trafik från en filial slutar på en gateway vars LAN inte innehåller applikationen du ombads nå. Servern ligger i ett andra datacenter, bakom en intern länk som VPN:et aldrig konfigurerade. Att lägga till ännu ett prefix på den nära gatewayen gör ingenting för det fallet, eftersom den avlägsna gatewayen är en krypteringsändpunkt och inte den sista routern. Vägen behöver en rutt vidare, ett tillträde vid den avlägsna säkerhetsgränsen och ett returbeslut i destinationens eget nätverk.

Den avlägsna gatewayen är en krypteringsändpunkt

IPsec mellan gateways skyddar trafik mellan två säkerhetsenheter, och de inre adresserna färdas krypterade över det segmentet. Bortom den avlägsna gatewayen tar vanlig routning över, inklusive alla policyer som finns mellan datacenter. Det skyddade segmentet täcker därför en del av resan och inte resten. Att anta något annat är hur en design slutar med en frisk tunnel och en oåtkomlig applikation.

Rita vägen i tre delar: filial till nära gateway, nära till avlägsen gateway, avlägsen gateway till applikationen. Varje del har sin egen ägare och sitt eget felläge.

Läs båda riktningarna av tunnelpolicyn

En tunnelpolicy skrivs vanligtvis ur den lokala sidans perspektiv, och det är just den vanan som ger upphov till delvisa konfigurationer. Båda parterna måste lista filialens källa och destinationen så som de kommer att synas inne i tunneln, inklusive alla översättningar som designen avser. Att bara uppdatera den nära änden ger en fas två-avvikelse som ser ut som ett routningsfel. Jämför de två policymängderna innan du rör någon rutt.

Skriv källa och destination som adresser i stället för webbplatsnamn. Otydlighet här dyker senare upp som en förbryllande asymmetri.

Lägg till vägen vidare och bekräfta tillträdet

Den avlägsna gatewayen behöver en rutt mot applikationens subnät, och varje router däremellan måste tillåta filialens källa. Verifiera vad den avlägsna gatewayen faktiskt har i stället för vad diagrammet påstår.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

Det första kommandot rapporterar det utgående gränssnittet och nästa hopp som den avlägsna gatewayen skulle välja för den källan, en fråga som en vanlig routingtabell inte kan svara på. Spåret visar var paketen stannar, och ett brott efter den avlägsna gatewayen pekar på intern transitering och inte på tunneln. När rutten finns och trafiken ändå försvinner, fånga på den avlägsna gatewayen och läs källadressen som anländer, eftersom en oväntad adress betyder att översättning sker någonstans oplanerat. Alla adresser här är platshållare, så byt ut dem mot de riktiga subnäten för filial, transitering och applikation.

Testa från filialen och testa sedan den gamla vägen igen

Acceptans kräver en riktig källa i stället för en sondering från den avlägsna gatewayen. Kör kontrollen från en värd i filialen och behåll de tidigare fungerande destinationerna i samma test.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Ett svar från applikationen bevisar vägen fram och returvägen tillsammans, medan ping till den gamla destinationen bevisar att ändringen inte bröt det som redan fungerade. Fånga källadressen som applikationen loggar, eftersom dess åtkomstregler och varje returrutt måste matcha det värdet. Där filialen översätter före tunneln skiljer sig policyadressen och adressen som applikationen ser åt designen, så notera båda. Upprepa testet efter en nyckelförnyelse eller en routingändring, eftersom dessa vägar tenderar att valideras en gång och sedan glömmas.

Tilldela en ägare till var och en av de tre segmenten och till returrutten inne i destinationsnätverket. En väg med fyra ägare misslyckas i luckorna mellan dem.