Azure VPN između lokacija s partnerom iza NAT-a: kontrolni popis
NAT-T obrađuje samo vanjske pakete, ne adresu partnera ni unutarnje rute. Pet poredanih provjera odvaja problem prijevoda od problema konfiguracije.
Prođite ove provjere redom i zaustavite se na prvoj koja ne uspije. Većina prijava da Azure ne podržava uređaj iza NAT-a zapravo su adresa partnera do koje Azure ne može doći ili tunel koji nikad ne počinje s prave strane. Vanjski prijevoz i unutarnje usmjeravanje dva su različita problema, a njihovo miješanje troši poslijepodne. Svaki korak u nastavku daje zapažanje koje možete predati nekome drugome.
Korak 1: potvrdite da je partner uopće iza NAT-a
Usporedite adresu na WAN sučelju uređaja s adresom koju Azure vidi za njega. Ako se razlikuju, nešto prevodi, i taj prevoditelj sada je dio vašeg VPN dizajna. Pitajte pružatelja je li mapiranje statično ili dijeljeno, jer dijeljeno mapiranje mijenja ono na što se možete osloniti. Uređaj s privatnom WAN adresom i bez prosljeđivanja drugi je slučaj od onoga iza NAT-a na razini operatera sa stabilnim javnim mapiranjem.
Ako se dvije adrese podudaraju, zaustavite se ovdje: NAT nije vaš problem i ostatak ovog popisa neće pomoći.
Zapišite obje adrese i model prevoditelja u tiket. Taj jedan redak sprječava sljedeći krug pitanja zašto konfigurirani partner ne odgovara.
Korak 2: dogovorite tko inicira
Česta pitanja o Azure VPN Gateway navode podršku za NAT-T i dodaju da lokalni uređaj treba inicirati IPsec tunel kada se nalazi iza NAT-a. To odgovara načinu na koji radi prijevod sa stanjem, jer prevoditelj drži mapiranje zato što je unutarnji uređaj poslao prvi paket. Ako se očekuje da inicira Azure, a ništa ne dolazi da stvori to mapiranje, tunel nikad ne počinje.
Konfigurirajte partnera tako da pogreška samo-odgovarajuće strane bude očita, i provjerite pokušava li uređaj ponovno sam ili treba okidač. Neki uređaji podižu tunel samo kad se pojavi zanimljiv promet, što je u redu dok zanimljiv promet nije zdravstvena provjera koja nikad ne dolazi.
Promatrajte IKE razmjenu na uređaju tijekom ručnog iniciranja; tišina ondje je odgovor usmjeravanja ili vatrozida, ne odgovor Azurea.
Korak 3: postavite adresu partnera ispravno
Azure treba dostupnu javnu adresu partnera u svom objektu lokalnog mrežnog pristupnika, obično javnu adresu prevoditelja umjesto unutarnje adrese uređaja. Identitet kojim se uređaj autentificira zasebno je polje i može se legitimno razlikovati od adrese na koju Azure zove. Držite ih odvojenima, jer zamjena stvara pogrešku autentifikacije koja izgleda točno kao problem s NAT-om.
Ako se javna adresa promijeni, taj se objekt mora promijeniti s njom. Ime koje se razrješava na zastarjelu adresu gore je od statične adrese koju morate ručno ažurirati.
Zapišite sve tri vrijednosti: lokalnu adresu uređaja, prevedenu javnu adresu i konfigurirani identitet partnera.
Korak 4: otvorite samo portove koje NAT-T treba
NAT-T prenosi ESP unutar UDP-a, a RFC 3948 opisuje to enkapsuliranje s portom 4500 koji se koristi nakon početnog pregovaranja na portu 500. Vaš vatrozid i prevoditelj moraju dopuštati razmjenu i njezin povratni promet. Dopuštanje nepovezanog TCP porta ne dokazuje ništa o tom putu, a pravilo koje dopušta odlazni promet ali ne odgovor i dalje će propasti.
Statično prosljeđivanje dolaznog porta nije automatski potrebno kada partner inicira i prevoditelj drži stanje. Postaje nužno kada je mapiranje nestabilno ili kada nešto na putu agresivno isteče stanje.
Snimite jednom s obje strane prevoditelja; razlika u enkapsuliranju odmah je vidljiva.
Korak 5: odvojite vanjski prijevoz od unutarnjeg usmjeravanja
Tunel koji se uspostavi i ništa ne prenosi problem je usmjeravanja, ne NAT-T. Lokacije i dalje trebaju kompatibilne birače prometa, odgovarajuće adresne prostore, pravila pristupa i povratni put za aplikacijske mreže. Ništa od toga ne pruža uspješna IKE razmjena.
Ako dvije lokacije koriste preklapajuće privatne raspone, prijevod unutar tunela zaseban je dizajn sa svojim pravilima. Ne prenumerirajte podmrežu samo zato što se vanjski pristupnik nalazi iza kućnog usmjerivača.
Klasificirajte kvar po fazi prije nego što bilo što promijenite, i zadržite tu klasifikaciju u tiketu kako bi sljedeća osoba počela ondje gdje ste stali.