Azure side-tot-side VPN mei in peer efter NAT: kontrolelist

Wurkje dizze kontrôles yn oarder ôf en stop by de earste dy’t mislearret. De measte rapporten dat Azure in apparaat efter NAT net stypet, blykje in peeradres te wêzen dat Azure net berikke kin, of in tunnel dy’t nea fan de krekte kant begjint. It bûtenste ferfier en de binnenste rûte binne twa ferskillende problemen, en se trochinoar helje ferspilet in middei. Eltse stap hjirûnder leveret in observaasje dy’t jo oan immen oars jaan kinne.

Stap 1: befêstigje dat de peer hielendal efter NAT sit

Fergelykje it adres op de WAN-ynterfaasje fan it apparaat mei it adres dat Azure derfoar sjocht. As se ferskille, oersetet der wat, en dy oersetter is no diel fan jo VPN-ûntwerp. Freegje de provider oft de mapping statysk of dield is, want in dielde mapping feroaret wêr’t jo fertrouwe kinne. In apparaat mei in privee WAN-adres en gjin trochstjoering is in oar gefal as ien efter in carrier-grade NAT mei in stabile iepenbiere mapping.

As de twa adressen oerienkomme, stop hjir: NAT is net jo probleem en de rest fan dizze list sil net helpe.

Skriuw beide adressen en it model fan de oersetter yn it ticket. Dy iene rigel foarkomt de folgjende rûne fragen oer wêrom’t de konfigurearre peer net antwurdet.

Stap 2: kom oerien wa’t begjint

De Azure VPN Gateway FAQ neamt NAT-T-stipe en foeget ta dat it lokale apparaat de IPsec-tunnel begjinne moat as it efter NAT sit. Dat past by hoe’t stateful oersetting wurket, om’t de oersetter in mapping hâldt om’t it binnenapparaat it earste pakket stjoerd hat. As der fan Azure ferwachte wurdt dat it begjint en der komt neat om dy mapping te meitsjen, begjint de tunnel nea.

Konfigurearje de peer sa dat in flater fan allinnich-antwurder dúdlik is, en kontrolearje oft it apparaat sels wer besiket of in trigger nedich hat. Guon apparaten bringe in tunnel allinnich op as der nijsgjirrich ferkear ferskynt, wat goed is oant it nijsgjirrige ferkear in sûnensprobe is dy’t nea komt.

Sjoch it IKE-útwiksel op it apparaat by in hânmjittige begjin; stilte dêr is in antwurd fan rûte of firewall, net in antwurd fan Azure.

Stap 3: krij it peeradres goed

Azure hat in berikber iepenbier adres nedich foar de peer yn syn objekt foar pleatslike netwurkpoarte, meastentiids it iepenbiere adres fan de oersetter yn stee fan it binnenadres fan it apparaat. De identiteit wêrmei’t it apparaat autentisearret is in apart fjild en kin fan rjochtswege ferskille fan it adres dat Azure kielet. Hâld de twa rjocht, want se ferwikselje jout in autentikaasjeflater dy’t der krekt as in NAT-probleem útsjocht.

As it iepenbiere adres feroaret, moat dat objekt dermei feroarje. In namme dy’t nei in ferâldere adres oplost is slimmer as in statysk adres dat jo mei de hân bywurkje moatte.

Skriuw alle trije wearden op: lokaal adres fan it apparaat, oerset iepenbier adres, konfigurearre peeridentiteit.

Stap 4: iepenje allinnich de poarten dy’t NAT-T nedich hat

NAT-T draacht ESP binnen UDP, en RFC 3948 beskriuwt dy ynkapseling mei poarte 4500 brûkt nei de earste ûnderhanneling op poarte 500. Jo firewall en de oersetter moatte beide it útwiksel en syn weromferkear tastean. In net besibbe TCP-poarte tastean bewiist neat oer dit paad, en in regel dy’t útgjend tastiet mar net it antwurd sil noch altyd mislearje.

In statyske trochstjoering fan binnenkommende poarte is net automatysk nedich as de peer begjint en de oersetter steat hâldt. It wurdt nedich as de mapping ûnstabel is of as wat op it paad de steat agressyf ferrint.

Fang ien kear oan beide kanten fan de oersetter; it ferskil yn ynkapseling is fuortendaliks te sjen.

Stap 5: skiede bûtenst ferfier fan binnenste rûte

In tunnel dy’t him festiget en neat draacht is in rûteprobleem, gjin NAT-T-probleem. De siden hawwe noch hieltyd ferienbere ferkearsselektearders, oerienkommende adresromten, tagongsregels en in werompaad foar de applikaasjenetwurken nedich. Dêrfan leveret in slagge IKE-útwiksel neat.

As de twa siden oerlaapjende privee berikken brûke, is oersetting binnen de tunnel in apart ûntwerp mei syn eigen regels. Fernûmerje gjin subnet allinnich om’t de bûtenste poarte tafallich efter in hûsrûter sit.

Klassifisearje de flater per stap foar’t jo wat feroarje, en hâld dy klassifikaasje yn it ticket sadat de folgjende persoan begjint wêr’t jo opholden binne.