Udvidelse af websteds-VPN: følg returruten forbi gatewayen

Trafik fra en filial ender på en gateway, hvis LAN ikke indeholder det program, du blev bedt om at nå. Serveren ligger i et andet datacenter, over en intern forbindelse, som VPN’en aldrig konfigurerede. At tilføje endnu et præfiks på den nære gateway gør intet for det tilfælde, fordi den fjerne gateway er et krypteringsendepunkt og ikke den sidste router. Vejen har brug for en rute videre, en adgang ved den fjerne sikkerhedsgrænse og en returbeslutning i destinationens eget netværk.

Den fjerne gateway er et krypteringsendepunkt

IPsec mellem gateways beskytter trafik mellem to sikkerhedsenheder, og de indre adresser rejser krypteret gennem det segment. Bag den fjerne gateway overtager almindelig routing, inklusive enhver politik, der findes mellem datacentre. Det beskyttede segment dækker derfor en del af rejsen og ikke resten. At antage andet er, hvordan et design ender med en sund tunnel og et utilgængeligt program.

Tegn vejen i tre dele: filial til nær gateway, nær til fjern gateway, fjern gateway til programmet. Hver del har sin egen ejer og sin egen fejltilstand.

Læs begge retninger af tunnelpolitikken

En tunnelpolitik skrives normalt fra den lokale sides perspektiv, og netop den vane er oprindelsen til delvise konfigurationer. Begge parter skal angive filialkilden og destinationen, som de vil fremstå inde i tunnelen, inklusive enhver oversættelse, som designet tilsigter. Opdatering af kun den nære ende giver en fase-to-uoverensstemmelse, der ligner en routingfejl. Sammenlign de to politiksæt, før du rører nogen rute.

Skriv kilde og destination som adresser i stedet for webstedsnavne. Uklarhed her dukker senere op som en forvirrende asymmetri.

Tilføj ruten videre, og bekræft adgangen

Den fjerne gateway har brug for en rute mod programmets undernet, og hver router imellem skal tillade filialkilden. Kontroller, hvad den fjerne gateway faktisk har, i stedet for hvad 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 kommando rapporterer det udgående interface og næste hop, som den fjerne gateway ville vælge for den kilde, hvilket er et spørgsmål, en almindelig routingtabel ikke kan besvare. Sporet viser, hvor pakkerne stopper, og et brud efter den fjerne gateway peger på intern transit og ikke på tunnelen. Når ruten findes, og trafikken stadig forsvinder, så optag på den fjerne gateway og læs den ankommende kildeadresse, fordi en uventet adresse betyder, at oversættelse sker et uplanlagt sted. Alle adresser her er pladsholdere, så indsæt de rigtige undernet for filial, transit og program.

Test fra filialen, og test derefter den gamle vej igen

Accept kræver en rigtig kilde i stedet for en probe fra den fjerne gateway. Kør kontrollen fra en vært i filialen, og behold de tidligere fungerende destinationer i samme test.

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

Et svar fra programmet beviser vejen frem og returvejen sammen, mens ping til den gamle destination beviser, at ændringen ikke brød det, der allerede virkede. Registrer den kildeadresse, som programmet logger, fordi dets adgangsregler og enhver returrute skal matche den værdi. Hvor filialen oversætter før tunnelen, afviger politikadressen og den adresse, programmet ser, med vilje, så noter begge. Gentag testen efter en nøglefornyelse eller en routingændring, fordi disse veje har en tendens til at blive valideret én gang og derefter glemt.

Tildel en ejer til hvert af de tre segmenter og til returruten inde i destinationsnetværket. En vej med fire ejere fejler i hullerne mellem dem.