Utvidelse av nettstedets VPN: følg returruten forbi gatewayen

Trafikk fra en filial ender på en gateway der LAN-et ikke inneholder applikasjonen du ble bedt om å nå. Serveren ligger i et andre datasenter, bak en intern forbindelse som VPN-et aldri konfigurerte. Å legge til ett prefiks til på den nære gatewayen gjør ingenting for det tilfellet, fordi den fjerne gatewayen er et krypteringsendepunkt og ikke den siste ruteren. Veien trenger en rute videre, en tillatelse ved den fjerne sikkerhetsgrensen og en returbeslutning i destinasjonens eget nettverk.

Den fjerne gatewayen er et krypteringsendepunkt

IPsec mellom gatewayer beskytter trafikk mellom to sikkerhetsenheter, og de indre adressene reiser kryptert over det segmentet. Bak den fjerne gatewayen overtar vanlig ruting, inkludert enhver policy som finnes mellom datasentre. Det beskyttede segmentet dekker derfor en del av reisen og ikke resten. Å anta noe annet er hvordan et design ender opp med en sunn tunnel og en utilgjengelig applikasjon.

Tegn veien i tre deler: filial til nær gateway, nær til fjern gateway, fjern gateway til applikasjonen. Hver del har sin egen eier og sin egen feilmodus.

Les begge retningene av tunnelpolicyen

En tunnelpolicy skrives vanligvis fra den lokale sidens perspektiv, og nettopp den vanen er opphavet til delvise konfigurasjoner. Begge parter må liste filialkilden og destinasjonen slik de vil fremstå inne i tunnelen, inkludert enhver oversettelse designet forutsetter. Å oppdatere bare den nære enden gir en fase-to-avvik som ser ut som en rutingfeil. Sammenlign de to policysettene før du rører noen rute.

Skriv kilde og destinasjon som adresser i stedet for nettstedsnavn. Uklarhet her dukker senere opp som en forvirrende asymmetri.

Legg til ruten videre og bekreft tillatelsen

Den fjerne gatewayen trenger en rute mot applikasjonens subnett, og hver ruter imellom må tillate filialkilden. Verifiser hva den fjerne gatewayen faktisk har, i stedet for hva 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

Den første kommandoen rapporterer det utgående grensesnittet og neste hopp som den fjerne gatewayen ville velge for den kilden, et spørsmål en vanlig rutetabell ikke kan svare på. Sporet viser hvor pakkene stopper, og et brudd etter den fjerne gatewayen peker på intern transitt og ikke på tunnelen. Når ruten finnes og trafikken likevel forsvinner, ta opp på den fjerne gatewayen og les kildeadressen som kommer inn, fordi en uventet adresse betyr at oversettelse skjer et uplanlagt sted. Alle adressene her er plassholdere, så bytt ut med de ekte subnettene for filial, transitt og applikasjon.

Test fra filialen, og test deretter den gamle veien på nytt

Godkjenning krever en ekte kilde i stedet for en sondering fra den fjerne gatewayen. Kjør kontrollen fra en vert i filialen og behold de tidligere fungerende destinasjonene i samme test.

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

Et svar fra applikasjonen beviser veien frem og returveien sammen, mens ping til den gamle destinasjonen beviser at endringen ikke ødela det som allerede virket. Ta opp kildeadressen som applikasjonen logger, fordi tilgangsreglene og enhver returrute må samsvare med den verdien. Der filialen oversetter før tunnelen, avviker policyadressen og adressen applikasjonen ser, med vilje, så noter begge. Gjenta testen etter en nøkkelfornyelse eller en rutingendring, fordi disse veiene har en tendens til å bli validert én gang og deretter glemt.

Tildel en eier til hvert av de tre segmentene og til returruten inne i destinasjonsnettverket. En vei med fire eiere feiler i hullene mellom dem.