Azure site-tot-site VPN met ’n eweknie agter NAT: kontrolelys

Werk hierdie kontroles in volgorde deur en stop by die eerste een wat misluk. Die meeste verslae dat Azure ’n toestel agter NAT nie ondersteun nie, blyk ’n eweknie-adres te wees wat Azure nie kan bereik nie, of ’n tonnel wat nooit van die regte kant af begin nie. Die buitenste vervoer en die binneroetering is twee verskillende probleme, en om hulle te vermeng mors ’n middag. Elke stap hieronder lewer ’n waarneming wat jy aan iemand anders kan gee.

Stap 1: bevestig dat die eweknie hoegenaamd agter NAT is

Vergelyk die adres op die toestel se WAN-koppelvlak met die adres wat Azure vir hom sien. As hulle verskil, is iets besig om te vertaal, en daardie vertaler is nou deel van jou VPN-ontwerp. Vra die verskaffer of die kartering staties of gedeel is, want ’n gedeelde kartering verander waarop jy kan staatmaak. ’n Toestel met ’n private WAN-adres en geen deurstoering is ’n ander geval as een agter ’n carrier-grade NAT met ’n stabiele openbare kartering.

As die twee adresse ooreenstem, stop hier: NAT is nie jou probleem nie en die res van hierdie lys sal nie help nie.

Teken beide adresse en die vertaler se model in die kaartjie aan. Daardie een reël voorkom die volgende rondte vrae oor waarom die gekonfigureerde eweknie nie antwoord nie.

Stap 2: kom ooreen oor wie begin

Die Azure VPN Gateway FAQ noem NAT-T-ondersteuning en voeg by dat die plaaslike toestel die IPsec-tonnel moet begin wanneer dit agter NAT sit. Dit stem ooreen met hoe stateful vertaling werk, aangesien die vertaler ’n kartering hou omdat die binnetoestel die eerste pakket gestuur het. As daar van Azure verwag word om te begin en niks kom om daardie kartering te skep nie, begin die tonnel nooit nie.

Konfigureer die eweknie sodat ’n fout met slegs-reageerder duidelik is, en kyk of die toestel op sy eie weer probeer of ’n sneller nodig het. Sommige toestelle bring ’n tonnel net op wanneer interessante verkeer verskyn, wat goed is totdat die interessante verkeer ’n gesondheidstoets is wat nooit kom nie.

Kyk na die IKE-uitruiling op die toestel tydens ’n handmatige inisiasie; stilte daar is ’n roetering- of firewall-antwoord, nie ’n Azure-antwoord nie.

Stap 3: kry die eweknie-adres reg

Azure benodig ’n bereikbare openbare adres vir die eweknie in sy plaaslike netwerkpoortobjek, gewoonlik die vertaler se openbare adres eerder as die toestel se binne-adres. Die identiteit waarmee die toestel authentiseer is ’n aparte veld en kan wettig verskil van die adres wat Azure skakel. Hou die twee reg, want om hulle te ruil lewer ’n verifikasiefout wat presies soos ’n NAT-probleem lyk.

As die openbare adres verander, moet daardie objek saam verander. ’n Naam wat na ’n verouderde adres oplos, is slegter as ’n statiese een wat jy met die hand moet opdateer.

Skryf al drie waardes neer: toestel se plaaslike adres, vertaalde openbare adres, gekonfigureerde eweknie-identiteit.

Stap 4: maak net die poorte oop wat NAT-T nodig het

NAT-T dra ESP binne UDP, en RFC 3948 beskryf daardie inkapseling met poort 4500 wat gebruik word ná die aanvanklike onderhandeling op poort 500. Jou firewall en die vertaler moet albei die uitruiling en sy terugkeerverkeer toelaat. Om ’n onverwante TCP-poort toe te laat bewys niks oor hierdie pad nie, en ’n reël wat uitgaande verkeer toelaat maar nie die antwoord nie, sal steeds misluk.

’n Statiese inkomende poortdeurstuur is nie outomaties nodig wanneer die eweknie begin en die vertaler toestand hou nie. Dit word nodig wanneer die kartering onstabiel is of wanneer iets in die pad toestand aggressief laat verval.

Vang een keer aan beide kante van die vertaler; die verskil in inkapseling is onmiddellik sigbaar.

Stap 5: skei buitenste vervoer van binneroetering

’n Tonnel wat vestig en niks dra nie, is ’n roeteringsprobleem, nie ’n NAT-T-probleem nie. Die terreine het steeds versoenbare verkeerskeerders, ooreenstemmende adresruimtes, toegangsreëls en ’n terugpad vir die toepassingsnetwerke nodig. Niks daarvan word deur ’n suksesvolle IKE-uitruiling verskaf nie.

As die twee terreine oorvleuelende private reekse gebruik, is vertaling binne die tonnel ’n aparte ontwerp met sy eie reëls. Moet nie ’n subnet hernommer net omdat die buitenste poort toevallig agter ’n huisroeter sit nie.

Klassifiseer die fout volgens stadium voordat jy enigiets verander, en hou daardie klassifikasie in die kaartjie sodat die volgende persoon begin waar jy gestop het.