AWS na Azure-site-VPN: skryf eers die terugroete

Die tonnel sal opkom. Dit gebeur gewoonlik, want IKE het net ooreenstemmende voorstelle en ’n bereikbare eweknie-adres nodig. Wat daarna misluk, is die terugpad: die AWS-werklas stuur pakkette in ’n tonnel in, maar niks aan die Azure-kant weet hoe om 10.10.0.0/16 te antwoord nie, of die Azure-roete bestaan in ’n tabel wat die werklassubnet nie gebruik nie. Skryf die roetplan voordat jy enige konssole aanraak, en die tonnel word die minste interessante deel van die werk.

Stap 1: bevries die adresplan

Werk met konkrete waardes. ’n AWS-werklas sit op 10.10.1.20 binne 10.10.0.0/16 en het TCP 443 nodig na ’n Azure-diens op 10.20.1.30 binne 10.20.0.0/16. Die twee reekse mag nie oorvleuel nie, en die dienspaar, nie die tonnel nie, is die aanvaardingstoets.

Skryf daardie vier feite neer voordat jy enigiets anders doen, want elke latere stap word daarteen nagegaan.

Stap 2: noem die gateway wat elke kant besit

AWS Site-to-Site VPN kan op ’n virtuele privaat gateway of ’n transit gateway eindig, en dit is verskillende roete-eienaars. Azure bied sy bestuurde VPN Gateway en, apart, VM-gebaseerde toestelle wat klante self bestuur. Teken aan watter paar jy het, want die volgende sprong verskil in elke kombinasie.

Vir ’n bestuurde gateway, moenie ’n roete kopieer wat na ’n geraamde private toesteladres wys nie. Vir ’n toestel, moenie aanvaar dat wolkroetepropagasie die gasheerde bedryfstelsel opstel nie, want dit doen dit nie.

Om dit verkeerd te kry, lewer ’n plan wat volledig lyk en pakkette na ’n adres stuur wat nooit antwoord nie.

Stap 3: skryf die roete wat elke werklas werklik gebruik

Elke grens hieronder is ’n aparte opsoek, en ’n roete in een daarvan is nie ’n roete vir die pakket nie. Vul die tabel met jou eie waardes in voordat die tonnel lewendig gaan.

Op AWS is die werklassubnet se roetetabel joune om by te werk, selfs nadat BGP of ’n tonnel gesond is; die roet-oorsig beskou dit as deel van die verbinding. Op Azure word ’n gebruikergedefinieerde roetetabel aan ’n subnet gekoppel eerder as aan die virtuele netwerk, so kyk na die effektiewe roete by die werklas-NIC eerder as by die VNet-blad.

’n Bestuurde Azure-gateway kan die verre voorvoegsel deur gateway-propagasie leer, en ’n UDR kan daardie besluit oorheers. Voeg die UDR by wanneer jy ’n rede het, nie uit gewoonte nie. As jy een byvoeg, wys dit na die volgende sprong wat die gateway vir die VPN-pad publiseer eerder as om ’n toesteladres te versin. Lees dan die effektiewe roetes op die NIC weer, want die NIC is waar die besluit werklik geneem word.

Stap 4: versoen die omvang

Vir BGP, vergelyk wat elke kant adverteer met wat die ander kant werklik geleer het, spesifieke voorvoegsel vir spesifieke voorvoegsel. Vir statiese roetering, vergelyk die gekonfigureerde verre reekse met die werklasroetes wat jy in stap 3 geskryf het.

’n IKE-verhouding wat oor kriptografie saamstem, is nie bewys dat enige kant 10.10.0.0/16 of 10.20.0.0/16 geleer het nie. Twee tonnels kan op wees terwyl een kant ’n enkele /24 adverteer in plaas van die /16 wat jy beplan het. Kyk na die voorvoegsel in die roetetabel, nie in die tonnelstatus nie. Die wanverhouding wys later as een werkende subnet en een wat nooit antwoord nie.

Stap 5: toets die diens, vanaf die werklike bron

Laat die beoogde vloei toe in AWS-sekuriteitsgroepe en netwerk-ACL’s, in Azure NSG’s, en in enige toestelfilter in die pad. Maak dan een verbinding van 10.10.1.20 na die goedgekeurde diensadres en -poort oop en bevestig dat die antwoord na dieselfde bron terugkom.

Beide wolk-sekuriteitsgroepe en NSG’s is stateful, so ’n geweierde terugpakket is ’n roete-simptoom eerder as ’n reël wat jy vergeet het om omgekeerd te skryf.

’n Ping van enige gateway beslis niks. ICMP na ’n gateway-adres oefen die beheervlak-pad, nie die geforwarde TCP-diens wat die werklas nodig het nie.

Terugrol en rekords

Teken die roete-eienaars langs die tonnel-identifiseerders aan, en hou die roetetabelle van voor die verandering. As die verandering uitgehaal moet word, verwyder die werklasroetes voordat jy die tonnel afbreek, sodat geen subnet aan ’n volgende sprong wys wat nie meer bestaan nie.

’n Latere subnet-skuif of spoke-koppeling het dan een bepaalde plek om by te werk, in plaas van ’n werkende tonnel wat die skuld kry vir ’n roete wat dit nooit besit het nie.