VPN-terreinuitbreiding: volg die terugroete verby die poort

Verkeer van ’n tak eindig op ’n poort wie se LAN nie die toepassing bevat wat jy gevra is om te bereik nie. Die bediener staan in ’n tweede datasentrum, oor ’n interne skakel wat die VPN nooit opgestel het nie. Nog ’n voorvoegsel by die nabye poort voeg niks by vir daardie geval nie, want die verre poort is ’n enkripsie-eindpunt eerder as die laaste roeteerder. Die pad het ’n roete vorentoe nodig, ’n toelating by die verre sekuriteitsgrens en ’n terugkeerbesluit in die bestemming se eie netwerk.

Die verre poort is ’n enkripsie-eindpunt

Poort-tot-poort IPsec beskerm verkeer tussen twee sekuriteitstoestelle, en die binneste adresse reis geënkripteer oor daardie segment. Anderkant die verre poort neem gewone roetering oor, insluitend watter beleid ook al tussen datasentrums bestaan. Die beskermde segment dek dus ’n deel van die reis en nie die res nie. Om anders aan te neem, is hoe ’n ontwerp met ’n gesonde tonnel en ’n onbereikbare toepassing eindig.

Teken die pad in drie dele: tak na nabye poort, nabye na verre poort, verre poort na die toepassing. Elke deel het sy eie eienaar en sy eie foutmodus.

Lees beide rigtings van die tonnelbeleid

’n Tonnelbeleid word gewoonlik vanuit die plaaslike kant se perspektief geskryf, en daardie gewoonte is waar gedeeltelike konfigurasies vandaan kom. Beide eweknieë moet die takbron en die bestemming lys soos hulle binne die tonnel sal verskyn, insluitend enige vertaling wat die ontwerp beoog. Om net die nabye kant op te dateer, lewer ’n fase-twee-wanpassing wat soos ’n roeteringsfout lyk. Vergelyk die twee beleidstelle voordat jy enige roete aanraak.

Skryf bron en bestemming as adresse eerder as werfname. Dubbelsinnigheid hier duik later weer op as ’n raaiselagtige asimmetrie.

Voeg die roete vorentoe by en bevestig toelating

Die verre poort het ’n roete na die toepassingsubnet nodig, en elke roeteerder tussen hulle moet die takbron toelaat. Verifieer wat die verre poort werklik het eerder as wat die diagram beweer.

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

Die eerste opdrag rapporteer die uitgangsinterface en volgende sprong wat die verre poort vir daardie bron sou kies, wat ’n vraag is wat ’n gewone roeteringstabel nie kan beantwoord nie. Die spoor wys waar pakkette stop, en ’n onderbreking ná die verre poort dui op interne deurvoer eerder as op die tonnel. Wanneer die roete bestaan en verkeer steeds verdwyn, vang op die verre poort vas en lees die bronadres wat aankom, want ’n onverwagte adres beteken dat vertaling êrens onbeplan plaasvind. Alle adresse hier is plekhouers, so vervang die werklike tak-, deurvoer- en toepassingsubnette.

Toets vanaf die tak en hertoets dan die ou pad

Aanvaarding het ’n werklike bron nodig eerder as ’n peiling vanaf die verre poort. Voer die kontrole uit vanaf ’n tak-gasheer en hou die voorheen werkende bestemmings in dieselfde toets.

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

’n Antwoord van die toepassing bewys die pad vorentoe en die terugpad saam, terwyl die ping na die ou bestemming bewys dat die verandering nie breek wat reeds gewerk het nie. Teken die bronadres aan wat die toepassing log, want sy toegangsreëls en enige terugroete moet by daardie waarde pas. Waar die tak voor die tonnel vertaal, verskil die beleidadres en die adres wat die toepassing sien doelbewus, so teken albei aan. Herhaal die toets ná ’n sleutelvernuwing of ’n roeteringsverandering, want hierdie paaie word geneig om een keer gevalideer en dan vergeet.

Wys ’n eienaar aan elk van die drie segmente en aan die terugroete binne die bestemmingsnetwerk toe. ’n Pad met vier eienaars faal in die gapings tussen hulle.