Utviding av nettstad-VPN: følg returruta forbi gatewayen

Trafikk frå ein filial endar på ein gateway der LAN-et ikkje inneheld applikasjonen du vart beden om å nå. Tenaren ligg i eit andre datasenter, bak ei intern sambinding som VPN-et aldri konfigurerte. Å leggje til eitt prefiks til på den nære gatewayen gjer ingenting for det tilfellet, fordi den fjerne gatewayen er eit krypteringsendepunkt og ikkje den siste rutaren. Vegen treng ei rute vidare, ei tillating ved den fjerne tryggleiksgrensa og ei returbeslutning i det eigne nettet til destinasjonen.

Den fjerne gatewayen er eit krypteringsendepunkt

IPsec mellom gatewayar vernar trafikk mellom to tryggleikseiningar, og dei indre adressene reiser kryptert over det segmentet. Bak den fjerne gatewayen tek vanleg ruting over, inkludert kva som helst policy som finst mellom datasenter. Det verna segmentet dekkjer derfor ein del av reisa og ikkje resten. Å anta noko anna er korleis eit design endar opp med ein sunn tunnel og ein utilgjengeleg applikasjon.

Teikn vegen i tre delar: filial til nær gateway, nær til fjern gateway, fjern gateway til applikasjonen. Kvar del har sin eigen eigar og sin eigen feilmodus.

Les begge retningane av tunnelpolicyen

Ein tunnelpolicy vert vanlegvis skriven frå perspektivet til den lokale sida, og nettopp den vanen er opphavet til delvise konfigurasjonar. Begge partar må liste filialkjelda og destinasjonen slik dei vil framstå inne i tunnelen, inkludert kva som helst omsetjing designet føreset. Å oppdatere berre den nære enden gir eit fase-to-avvik som ser ut som ein rutingfeil. Samanlikn dei to policysetta før du rører noka rute.

Skriv kjelde og destinasjon som adresser i staden for nettstadsnamn. Uklarleik her dukkar seinare opp som ein forvirrande asymmetri.

Legg til ruta vidare og stadfest tillatinga

Den fjerne gatewayen treng ei rute mot subnettet til applikasjonen, og kvar rutar imellom må tillate filialkjelda. Stadfest kva den fjerne gatewayen faktisk har, i staden for kva 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åande grensesnittet og neste hopp som den fjerne gatewayen ville velje for den kjelda, eit spørsmål ein vanleg rutetabell ikkje kan svare på. Sporet viser kvar pakkane stoppar, og eit brot etter den fjerne gatewayen peikar på intern transitt og ikkje på tunnelen. Når ruta finst og trafikken likevel forsvinn, ta opp på den fjerne gatewayen og les kjeldeadressa som kjem inn, fordi ei uventa adresse betyr at omsetjing skjer ein uplanlagd stad. Alle adressene her er plasshaldarar, så byt ut med dei ekte subnetta for filial, transitt og applikasjon.

Test frå filialen, og test deretter den gamle vegen på nytt

Godkjenning krev ei ekte kjelde i staden for ein sondering frå den fjerne gatewayen. Køyr kontrollen frå ein vert i filialen og hald på dei tidlegare fungerande destinasjonane i same test.

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

Eit svar frå applikasjonen beviser vegen fram og returvegen saman, medan ping til den gamle destinasjonen beviser at endringa ikkje øydela det som allereie virka. Ta opp kjeldeadressa som applikasjonen loggar, fordi tilgangsreglane og kvar returrute må samsvare med den verdien. Der filialen omset før tunnelen, avvik policyadressa og adressa applikasjonen ser, med vilje, så noter begge. Gjenta testen etter ei nøkkelfornying eller ei rutingendring, fordi desse vegane har ein tendens til å bli validerte éin gong og deretter gløymde.

Tildel ein eigar til kvar av dei tre segmenta og til returruta inne i destinasjonsnettet. Ein veg med fire eigarar feilar i hola mellom dei.