Site-to-Site VPN fan AWS nei Azure: skriuw earst de weromrûte
In ferbûne tunnel tusken wolken bewiist neat oant elk wurklêstsubnet nei it fiere prefiks rûtet. Wurkje it plan yn folchoarder ôf en test dan de tsjinst.
De tunnel sil omheech komme. Dat giet meastentiids sa, want IKE hat allinnich oerienkommende útstellen en in berikber peer-adres nedich. Wat dêrnei misgiet, is de weromwei: de AWS-wurklêst stjoert pakketten in tunnel yn, mar neat oan ’e Azure-kant wit hoe’t it 10.10.0.0/16 beantwurdzje moat, of de Azure-rûte bestiet yn in tabel dy’t it wurklêstsubnet net brûkt. Skriuw it rûteplan foardat jo ien fan ’e konsoles oanreitsje, en de tunnel wurdt it minst nijsgjirrige diel fan it wurk.
Stap 1: friez it adresplan
Wurkje mei konkrete wearden. In AWS-wurklêst sit op 10.10.1.20 binnen 10.10.0.0/16 en hat TCP 443 nedich nei in Azure-tsjinst op 10.20.1.30 binnen 10.20.0.0/16. De twa berikken meie net oerlaapje, en de tsjinstpear, net de tunnel, is de akseptaasjetest.
Skriuw dy fjouwer feiten op foardat jo wat oars dogge, want elke lettere stap wurdt dêr tsjin kontrolearre.
Stap 2: neam de gateway dy’t elk ein besit
AWS Site-to-Site VPN kin einigje op in firtuele partikuliere gateway of op in transit-gateway, en dat binne ferskillende rûte-eigners. Azure biedt syn behearderde VPN Gateway en, apart, VM-basearre apparaten dy’t klanten sels rinne litte. Skriuw op hokker pear jo hawwe, want de folgjende sprong ferskilt yn elke kombinaasje.
Foar in behearderde gateway, kopiearje gjin rûte dy’t nei in betocht partikulier apparaatadres wiist. Foar in apparaat, nim net oan dat rûtepropagaasje yn ’e wolk it gastbestjoeringssysteem konfigurearret, want dat docht it net.
Dit ferkeard dwaan jout in plan dat folslein liket en pakketten stjoert nei in adres dat nea antwurdet.
Stap 3: skriuw de rûte dy’t elke wurklêst echt brûkt
Elke grins hjirûnder is in aparte opsyk, en in rûte yn ien fan har is gjin rûte foar it pakket. Folje de tabel yn mei jo eigen wearden foardat de tunnel libben giet.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
Op AWS is de rûtetabel fan it wurklêstsubnet fan jo om by te wurkjen, sels nei’t BGP of in tunnel sûn is; it oersjoch fan rûtering beskôget dat as part fan ’e ferbining. Op Azure wurdt in troch de brûker definiearre rûtetabel oan in subnet keppele ynstee fan oan it firtuele netwurk, dus kontrolearje de effektive rûte by de NIC fan ’e wurklêst en net by it VNet-blêd.
In behearderde Azure-gateway kin it fiere prefiks troch gatewaypropagaasje leare, en in UDR kin dat beslút oerskriuwe. Foegje de UDR ta as jo in reden hawwe, net by refleks. As jo ien tafoegje, rjochtsje it dan op ’e folgjende sprong dy’t de gateway foar it VPN-paad publisearret ynstee fan in apparaatadres te betinken. Lês dan de effektive rûtes op ’e NIC opnij, want dêr wurdt it beslút eins nommen.
Stap 4: bring de omfang yn oerienstimming
Foar BGP, fergelykje wat elke kant oankundiget mei wat de oare kant echt leard hat, prefiks by prefiks. Foar statyske rûtering, fergelykje de konfigurearre fiere berikken mei de wurklêstrûtes dy’t jo yn stap 3 skreaun hawwe.
In IKE-relaasje dy’t it oer kryptografy iens is, is gjin bewiis dat ien kant 10.10.0.0/16 of 10.20.0.0/16 leard hat. Twa tunnels kinne omheech wêze wylst ien kant in inkeld /24 oankundiget ynstee fan it /16 dat jo beplene hawwe. Kontrolearje it prefiks yn ’e rûtetabel, net yn ’e tunnelstatus. De misferhâlding docht him letter foar as ien wurkjend subnet en ien dat nea antwurdet.
Stap 5: test de tsjinst, fan ’e echte boarne
Lit de bedoelde stream ta yn AWS-feilichheidsgroepen en netwurk-ACL’s, yn Azure NSG’s, en yn elk apparaatfilter op it paad. Iepenje dan ien ferbining fan 10.10.1.20 nei it goedkarde tsjinstadres en -poarte en befêstigje dat it antwurd nei deselde boarne weromkomt.
Sawol wolkfeilichheidsgroepen as NSG’s binne stateful, dus in wegere werompakket is in rûtesymtoom, net in regel dy’t jo fergetten binne om omkeard te skriuwen.
In ping fan hokker gateway dan ek beslist neat. ICMP nei in gatewayadres oefenet it paad fan it kontrôleflak, net de trochstjoerde TCP-tsjinst dy’t de wurklêst nedich hat.
Weromdraaie en registraasjes
Skriuw de rûte-eigners njonken de tunnelidentifikaasjes op en bewarje de rûtetabellen fan foar de wiziging. As de wiziging derút moat, ferwiderje dan de wurklêstrûtes foardat jo de tunnel ôfbrekke, sadat gjin subnet nei in folgjende sprong wiist dy’t net mear bestiet.
In lettere subnetferpleatsing of spoke-oansluting hat dan ien bestimd plak om by te wurkjen, ynstee fan in wurkjende tunnel dy’t de skuld draacht foar in rûte dy’t er nea besiet.