FortiGate NAT:n takana: local-gw, localid ja julkinen IP

NAT:n takana oleva FortiGate voi omistaa 10.0.0.2 WAN-liitännällään, kun internet esittää sen osoitteena 198.51.100.40, ja molemmat luvut ovat todellisia. Osoite, johon laite sitoutuu, ja identiteetti, jonka se lähettää IKE-todennuksen aikana, ovat erillisiä valintoja, tehty eri kentissä, eri yleisöille. NAT kirjoittaa ulkoisen osoitteiston uudelleen matkalla; se ei kirjoita todennettua identiteettiä uudelleen siksi, mitä kaukainen peer odottaa. Useimmat vaiheen 1 virheet tässä muodossa johtuvat oikean arvon laittamisesta väärään kenttään.

Kolme arvoa, kolme omistajaa

Aloita nimeämällä kolme arvoa ja kuka omistaa kunkin. local-gw on osoite, jota FortiGate käyttää IKE:n lähteenä ulkoisella liitännällään, ja sen on oltava osoite, joka laitteella todella on. Julkinen päätepiste on NAT-laitteen osoite, ja se kuuluu sille, joka tekee käännöksen. IKE-identiteetti on merkkijono, jonka peer vertaa omaan konfiguraatioonsa, eikä sen tarvitse olla IP-osoite lainkaan.

Kenttien nimet ovat tarpeeksi lähellä houkutellakseen vaihtamiseen, ja se on ansa. localid ja localid-type kuvaavat tunnistamista; local-gw kuvaa paikallista sitomista.

Esimerkki tekee eron konkreettiseksi. FortiGatessa avaa config vpn ipsec phase1-interface, sitten set interface "wan1" ja set local-gw 10.0.0.2 — osoite, joka laatikolla on, ja juuri se saa IKE-socketin sitoutumaan onnistuneesti. Jätä local-gw arvoon 0.0.0.0 ja liitännän osoitetta käytetään, mikä on yleensä sama asia mutta vähemmän eksplisiittinen. Älä aseta local-gw arvoon 198.51.100.40, koska laite ei omista sitä osoitetta eikä socket sitoudu siihen. Kahden arvon saaminen näyttämään paperilla samalta ei ole konfiguraatio.

Vaihe 1: valitse identiteetti, jonka peer hyväksyy

Nyt identiteetti, joka on eri päätös. set localid ottaa arvon, jota peer vertaa, ja set localid-type kertoo FortiGatelle, miten se tulkitaan: osoite, FQDN, käyttäjän FQDN tai avaimen ID. auto kanssa laite johtaa sen, yleensä lähtevän liitännän osoitteesta, joka on täsmälleen se arvo, jota NAT-laite on muuttamassa.

Juuri tämä johtaminen on syy siihen, miksi eksplisiittinen identiteetti on tärkeä tässä topologiassa. Jos peer odottaa osoiteidentiteettiä, aseta localid-type address ja localid julkiseen osoitteeseen, jonka peer näkee, ja vahvista sitten, että peer hyväksyy tämän arvon identiteettinä eikä reitityskohteena. Jos peer odottaa FQDN:ää, käytä localid-type fqdn ja nimeä, jolla se konfiguroitiin. Vahvista, mitä todella lähetettiin komennolla diagnose vpn ike gateway list, joka näyttää yhdyskäytävän tilan ja käytössä olevat tunnisteet, ei sitä, mitä aioit kirjoittaa. Älä oleta, että identiteettityyppivaihtoehto hyväksyy mielivaltaisen ei-paikallisen osoitteen; tarkista ensin julkaisun dokumentoitu semantiikka.

Vaihe 2: välitä UDP 500 ja 4500 laitteelle

Kolmas arvo kuuluu NAT-laitteelle, ja se on se, jonka tarkistamisen ihmiset unohtavat. Julkisen päätepisteen on välitettävä UDP 500 ja UDP 4500 FortiGatelle, koska NAT-T:n tunnistus ja sitä seuraava kapseloitu ESP riippuvat molemmat siitä, että nämä portit saapuvat. Tämä suunnittelu olettaa yksi-yhteen-kartoituksen; yhden julkisen osoitteen porttipohjainen jakaminen useiden peerien kesken on eri topologia, jolla on eri rajat.

Vahvista välitys kaappauksella, ei toivolla: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 näyttää, saapuvatko paketit ja lähtevätkö vastaukset.

Google Cloud VPN dokumentoi yksi-yhteen NAT:n NAT-T:llä tuettuna järjestelynä NAT:n takana olevalle peerille, ja se on rajoitus, jonka mukaan on suunniteltava, jos kaukainen pää on Cloud VPN -yhdyskäytävä. Yksi-moneen tai porttipohjainen jakaminen ei ole sama tuettu topologia, eikä mikään paikallinen identiteetin viritys muuta sitä. Jos kaukainen puoli on muu laite, sen oma dokumentaatio määrittää, mitä se hyväksyy identiteettinä ja sietääkö se käännettyä peer-osoitetta. Lue se ennen paikallisen kentän muuttamista, koska paikallinen puoli ei voi neuvotella sääntöä, jota kaukainen puoli ei toteuta.

Vaihe 3: tarkista, mitä vaihe 1 ei ratkaise

NAT-läpäisy nostaa tunnelin, identiteettisopu päättää, hyväksyykö peer sen, ja sisemmän etuliitteen reititys päättää, mikä todella kulkee. Oikea paikallinen ID ei voi tarjota puuttuvaa staattista reittiä tai puuttuvaa liikenteen valitsinta.

Tarkista siis kerroksittain. get vpn ipsec tunnel details näyttää, onko tunneli ylhäällä ja mitkä valitsimet neuvoteltiin, ja ristiriita määritetyn kaukana olevan aliverkon ja neuvotellun valitsimen välillä on reititysongelma vaiheen 2 asussa. execute vpn ike gateway clear pakottaa uudelleenneuvottelun, joten testaat nykyistä konfiguraatiota etkä istuntoa, joka luotiin ennen viimeistä muutostasi. Lähetä sitten liikennettä kaukana olevan etuliitteen isäntään ja vahvista, että laskurit liikkuvat, koska ylhäällä oleva ja mitään läpäisemätön tunneli näyttää täsmälleen samalta kuin toimiva, kunnes tarkistat.

Pidä kolme arvoa yhdessä paikassa muistiinpanoissasi: paikallinen osoite, joka laitteella on, julkinen päätepiste, jonka NAT-laite esittää, ja identiteettimerkkijono, jota peer odottaa. Ne muuttuvat eri syistä ja eri aikoina.

NAT-laitteen uudelleennumerointi ei ole syy koskea FortiGaten local-gw -kenttään, eikä identiteetin muutos ole syy numeroida mitään uudelleen. Näiden kahden sekoittaminen on se, miten toimiva tunneli rakennetaan uudelleen asiattoman huoltokatkon aikana. Cloud VPN:n NAT-ohje on viite tuetulle topologialle sillä puolella.

Testi, joka ratkaisee asian, on tylsä ja nopea: kaappaa ulkoisella liitännällä, vahvista että UDP 500 ja 4500 saapuvat peeriltä, vahvista että IKE-vaihdon identiteetti vastaa sitä, mitä peer konfiguroitiin odottamaan, ja vahvista sitten, että neuvotellut valitsimet kattavat ne aliverkot, joilla on sinulle merkitystä. Jos ensimmäinen tarkistus epäonnistuu, epäilty on NAT-laite. Jos toinen epäonnistuu, kyse on identiteettikentistä. Jos kolmas epäonnistuu, NAT tai identiteetti ei ollut koskaan ongelma.