FortiGate už NAT: local-gw, localid ir viešasis IP

Už NAT esantis FortiGate gali turėti 10.0.0.2 savo WAN sąsajoje, o internetas jį rodo kaip 198.51.100.40, ir abu skaičiai yra tikri. Adresas, prie kurio prisiriša įrenginys, ir tapatybė, kurią jis siunčia IKE autentifikacijos metu, yra atskiri sprendimai, priimti atskiruose laukuose, atskirai auditorijai. NAT perrašo išorinį adresavimą kelyje; jis neperrašo autentifikuotos tapatybės į tai, ko tikisi tolimas peer. Dauguma 1 fazės gedimų šioje formoje kyla dėl to, kad teisinga reikšmė įrašoma į netinkamą lauką.

Trys reikšmės, trys savininkai

Pradėkite įvardydami tris reikšmes ir kas kiekvieną jų valdo. local-gw yra adresas, kurį FortiGate naudoja kaip IKE šaltinį išorinėje sąsajoje, ir jis turi būti adresas, kurį įrenginys tikrai turi. Viešasis galinis taškas yra NAT įrenginio adresas, priklausantis tam, kas atlieka vertimą. IKE tapatybė yra eilutė, kurią peer lygina su savo konfigūracija, ir ji visai neturi būti IP adresas.

Laukų pavadinimai pakankamai artimi, kad paskatintų pakeitimą, ir tai yra spąstai. localid ir localid-type apibūdina identifikavimą; local-gw apibūdina vietinį susiejimą.

Pavyzdys padaro skirtumą konkretų. FortiGate atidarykite config vpn ipsec phase1-interface, tada set interface "wan1" ir set local-gw 10.0.0.2 — adresas, kurį įrenginys turi, ir būtent tai leidžia IKE lizdui sėkmingai prisirišti. Palikite local-gw ties 0.0.0.0 ir bus naudojamas sąsajos adresas, kuris paprastai yra tas pats, bet mažiau aiškus. Nenustatykite local-gw į 198.51.100.40, nes įrenginys neturi šio adreso ir lizdas prie jo neprisiriš. Dviejų reikšmių padarymas vienodomis popieriuje nėra konfigūracija.

1 žingsnis: pasirinkite tapatybę, kurią peer priims

Dabar tapatybė, kuri yra kitas sprendimas. set localid paima reikšmę, kurią peer lygins, o set localid-type pasako FortiGate, kaip ją interpretuoti: adresas, FQDN, vartotojo FQDN arba rakto ID. Su auto įrenginys ją išveda, paprastai iš išeinančios sąsajos adreso, kuris yra būtent ta reikšmė, kurią NAT įrenginys ruošiasi pakeisti.

Būtent šis išvedimas yra priežastis, kodėl šioje topologijoje svarbi aiški tapatybė. Jei peer tikisi adreso tapatybės, nustatykite localid-type address ir localid į viešąjį adresą, kurį matys peer, tada patvirtinkite, kad peer priima šią reikšmę kaip tapatybę, o ne kaip maršrutizavimo tikslą. Jei peer tikisi FQDN, naudokite localid-type fqdn ir pavadinimą, su kuriuo ji buvo sukonfigūruota. Patikrinkite, kas iš tikrųjų buvo išsiųsta, naudodami diagnose vpn ike gateway list, kuri rodo šliuzo būseną ir naudojamus identifikatorius, o ne tai, ką ketinote įvesti. Nemanome, kad tapatybės tipo parinktis priima savavališką ne vietinį adresą; pirmiausia patikrinkite dokumentuotą leidimo semantiką.

2 žingsnis: persiųskite UDP 500 ir 4500 į įrenginį

Trečioji reikšmė priklauso NAT įrenginiui, ir tai yra ta, kurią žmonės pamiršta patikrinti. Viešasis galinis taškas turi persiųsti UDP 500 ir UDP 4500 į FortiGate, nes NAT-T aptikimas ir po jo einantis inkapsuliuotas ESP abu priklauso nuo to, ar šie prievadai atkeliauja. Šis projektas daro prielaidą, kad susiejimas vienas su vienu; vieno viešojo adreso dalijimasis pagal prievadus tarp kelių peer yra kita topologija su kitomis ribomis.

Patvirtinkite persiuntimą įrašu, o ne viltimi: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 rodo, ar paketai atkeliauja, ir ar atsakymai išeina.

Google Cloud VPN dokumentuoja NAT vienas su vienu su NAT-T kaip palaikomą išdėstymą peer už NAT, ir tai yra apribojimas, pagal kurį reikia projektuoti, jei tolimas galas yra Cloud VPN šliuzas. Dalijimasis vienas su daugeliu arba pagal prievadus nėra ta pati palaikoma topologija, ir joks vietinis tapatybės derinimas to nepakeis. Jei tolimoji pusė yra kitas įrenginys, jo paties dokumentacija nustato, ką jis priims kaip tapatybę ir ar toleruos išverstą peer adresą. Perskaitykite tai prieš keisdami vietinį lauką, nes vietinė pusė negali derėtis dėl taisyklės, kurios tolimoji pusė neįgyvendina.

3 žingsnis: patikrinkite, ko neišsprendžia 1 fazė

NAT perėjimas pakelia tunelį, tapatybės sutarimas nusprendžia, ar peer jį priims, o vidinio prefikso maršrutizavimas nusprendžia, kas iš tikrųjų praeina. Teisingas vietinis ID negali suteikti trūkstamo statinio maršruto ar trūkstamo srauto selektoriaus.

Todėl tikrinkite sluoksniais. get vpn ipsec tunnel details rodo, ar tunelis pakeltas ir kokie selektoriai suderėti, o neatitikimas tarp sukonfigūruoto tolimo poskyrio ir suderėto selektoriaus yra maršrutizavimo problema 2 fazės kostiumu. execute vpn ike gateway clear priverčia derėtis iš naujo, todėl bandote dabartinę konfigūraciją, o ne sesiją, nustatytą prieš jūsų paskutinį pakeitimą. Tada siųskite srautą į tolimo prefikso hostą ir patvirtinkite, kad skaitikliai juda, nes pakeltas ir nieko nepraleidžiantis tunelis atrodo identiškai kaip veikiantis, kol nepatikrinsite.

Laikykite tris reikšmes vienoje vietoje savo užrašuose: vietinį adresą, kurį turi įrenginys, viešąjį galinį tašką, kurį pateikia NAT įrenginys, ir tapatybės eilutę, kurios tikisi peer. Jos keičiasi dėl skirtingų priežasčių ir skirtingu metu.

NAT įrenginio pernumeravimas nėra priežastis liesti FortiGate local-gw lauką, o tapatybės pakeitimas nėra priežastis ką nors pernumeruoti. Sumaišius abu, veikiantis tunelis perstatomas nesusijusiame techninės priežiūros lange. Cloud VPN NAT gairės yra nuoroda į palaikomą topologiją toje pusėje.

Testas, kuris tai išsprendžia, yra nuobodus ir greitas: įrašykite išorinėje sąsajoje, patvirtinkite, kad UDP 500 ir 4500 ateina iš peer, patvirtinkite, kad IKE mainų tapatybė atitinka tai, ką peer buvo sukonfigūruotas tikėtis, tada patvirtinkite, kad suderėti selektoriai apima jums svarbius poskyrius. Jei pirmas patikrinimas nepavyksta, įtariamasis yra NAT įrenginys. Jei antras, tai tapatybės laukai. Jei trečias, nei NAT, nei tapatybė niekada nebuvo problema.