Azure-toimipaikka-VPN NAT:n takana olevan vastapuolen kanssa: tarkistuslista

Käy nämä tarkistukset järjestyksessä ja pysähdy ensimmäiseen, joka epäonnistuu. Useimmat ilmoitukset siitä, ettei Azure tue NAT:n takana olevaa laitetta, osoittautuvat vastapuolen osoitteeksi, johon Azure ei pääse, tai tunneliksi, joka ei koskaan käynnisty oikealta puolelta. Ulompi siirto ja sisäinen reititys ovat kaksi eri ongelmaa, ja niiden sekoittaminen tuhlaa iltapäivän. Jokainen alla oleva vaihe tuottaa havainnon, jonka voit antaa jollekin toiselle.

Vaihe 1: varmista, että vastapuoli on ylipäätään NAT:n takana

Vertaa laitteen WAN-liitännän osoitetta osoitteeseen, jonka Azure näkee sille. Jos ne eroavat, jokin kääntää, ja siitä kääntäjästä on nyt tullut osa VPN-suunnittelua. Kysy palveluntarjoajalta, onko kartoitus staattinen vai jaettu, koska jaettu kartoitus muuttaa sitä, mihin voit luottaa. Laite, jolla on yksityinen WAN-osoite eikä välitystä, on eri tapaus kuin laite operaattoritason NAT:n takana ja vakaalla julkisella kartoituksella.

Jos kaksi osoitetta täsmäävät, pysähdy tähän: NAT ei ole ongelmasi eikä muu tästä listasta auta.

Kirjaa molemmat osoitteet ja kääntäjän malli tikettiin. Se yksi rivi estää seuraavan kysymyskierroksen siitä, miksi määritetty vastapuoli ei vastaa.

Vaihe 2: sopikaa, kuka käynnistää

Azure VPN Gateway FAQ mainitsee NAT-T-tuen ja lisää, että paikallisen laitteen tulisi käynnistää IPsec-tunneli, kun se on NAT:n takana. Tämä vastaa sitä, miten tilallinen käännös toimii, sillä kääntäjä pitää kartoitusta siksi, että sisäinen laite lähetti ensimmäisen paketin. Jos Azurelta odotetaan käynnistystä eikä mitään saavu luomaan sitä kartoitusta, tunneli ei koskaan käynnisty.

Määritä vastapuoli niin, että vain-vastaaja-virhe on ilmeinen, ja tarkista, yrittääkö laite itsestään uudelleen vai tarvitseeko se liipaisimen. Jotkin laitteet nostavat tunnelin vain, kun kiinnostavaa liikennettä ilmaantuu, mikä on hyvä niin kauan kuin kiinnostava liikenne on terveystarkistus, joka ei koskaan tule.

Tarkkaile laitteen IKE-vaihtoa manuaalisen käynnistyksen aikana; hiljaisuus siinä on reitityksen tai palomuurin vastaus, ei Azuren vastaus.

Vaihe 3: aseta vastapuolen osoite oikein

Azure tarvitsee paikallisen verkkoyhdyskäytävän objektiin tavoitettavan julkisen osoitteen vastapuolelle, yleensä kääntäjän julkisen osoitteen eikä laitteen sisäistä osoitetta. Identiteetti, jolla laite todentaa itsensä, on erillinen kenttä ja voi laillisesti erota osoitteesta, johon Azure soittaa. Pidä kaksi erillään, sillä niiden vaihtaminen tuottaa todennusvirheen, joka näyttää täsmälleen NAT-ongelmalta.

Jos julkinen osoite muuttuu, objektin on muututtava sen mukana. Nimi, joka ratkeaa vanhentuneeseen osoitteeseen, on huonompi kuin staattinen osoite, jota sinun on päivitettävä käsin.

Kirjaa kaikki kolme arvoa: laitteen paikallinen osoite, käännetty julkinen osoite ja määritetty vastapuolen identiteetti.

Vaihe 4: avaa vain ne portit, jotka NAT-T tarvitsee

NAT-T kuljettaa ESP:tä UDP:n sisällä, ja RFC 3948 kuvaa sen kapseloinnin, jossa porttia 4500 käytetään portilla 500 käydyn alkuvaiheen neuvottelun jälkeen. Palomuurisi ja kääntäjän on molempien sallittava vaihto ja sen paluuliikenne. Asiaankuulumattoman TCP-portin salliminen ei todista mitään tästä polusta, ja sääntö, joka sallii lähtevän mutta ei vastausta, epäonnistuu silti.

Staattinen saapuvan portin välitys ei ole automaattisesti tarpeen, kun vastapuoli käynnistää ja kääntäjä pitää tilaa. Siitä tulee tarpeen, kun kartoitus on epävakaa tai kun jokin polulla vanhentaa tilan aggressiivisesti.

Kaappaa kerran kääntäjän molemmilta puolilta; kapseloinnin ero näkyy heti.

Vaihe 5: erota ulompi siirto sisäisestä reitityksestä

Tunneli, joka muodostuu eikä kuljeta mitään, on reititysongelma, ei NAT-T-ongelma. Sivustot tarvitsevat edelleen yhteensopivat liikenteen valitsimet, täsmäävät osoiteavaruudet, käyttösäännöt ja paluupolun sovellusverkoille. Mitään tästä ei tarjoa onnistunut IKE-vaihto.

Jos kaksi sivustoa käyttävät päällekkäisiä yksityisiä alueita, tunnelin sisäinen käännös on erillinen suunnittelu omine sääntöineen. Älä numeroi aliverkkoa uudelleen vain siksi, että ulompi yhdyskäytävä sattuu olemaan kotireitittimen takana.

Luokittele vika vaiheen mukaan ennen kuin muutat mitään, ja pidä luokittelu tiketissä, jotta seuraava aloittaa siitä, mihin sinä lopetit.