FortiGate NAT-i taga: local-gw, localid ja avalik IP

NAT-i taga olev FortiGate võib omada 10.0.0.2 oma WAN-liidesel, samal ajal kui internet esitab seda kui 198.51.100.40, ja mõlemad numbrid on reaalsed. Aadress, millega seade liitub, ja identiteet, mille see IKE autentimise ajal saadab, on eraldi otsused, tehtud eraldi väljadel, eraldi publikule. NAT kirjutab mööda minnes välise adresseeringu ümber; see ei kirjuta autenditud identiteeti ümber selleks, mida kauge peer ootab. Enamik faasi 1 tõrkeid selles vormis tuleb õige väärtuse panemisest valele väljale.

Kolm väärtust, kolm omanikku

Alustage kolme väärtuse ja nende omanike nimetamisest. local-gw on aadress, mida FortiGate kasutab IKE allikana oma välisliidesel, ja see peab olema aadress, mis seadmel tegelikult on. Avalik lõpp-punkt on NAT-seadme aadress ja kuulub sellele, kes tõlkimist teeb. IKE identiteet on string, mida peer võrdleb oma konfiguratsiooniga, ja see ei pea üldse olema IP-aadress.

Väljade nimed on piisavalt lähedased, et kutsuda asendamist, ja see on lõks. localid ja localid-type kirjeldavad identifitseerimist; local-gw kirjeldab kohalikku sidumist.

Näide teeb vahe konkreetseks. FortiGate'il avage config vpn ipsec phase1-interface, seejärel set interface "wan1" ja set local-gw 10.0.0.2 — aadress, mis karbil on, ja just see teeb IKE-pesa sidumise õnnestunuks. Jätke local-gw väärtusele 0.0.0.0 ja kasutatakse liidese aadressi, mis on tavaliselt sama asi, kuid vähem selge. Ärge seadke local-gw väärtusele 198.51.100.40, sest seade ei oma seda aadressi ja pesa ei seo end sellega. Kahe väärtuse paberil võrdseks muutmine ei ole konfiguratsioon.

Samm 1: valige identiteet, mille peer vastu võtab

Nüüd identiteet, mis on teistsugune otsus. set localid võtab väärtuse, mida peer võrdleb, ja set localid-type ütleb FortiGate'ile, kuidas seda tõlgendada: aadress, FQDN, kasutaja FQDN või võtme ID. auto korral tuletab seade selle, tavaliselt väljuva liidese aadressist, mis on täpselt see väärtus, mida NAT-seade hakkab muutma.

See tuletamine on põhjus, miks selgesõnaline identiteet selles topoloogias oluline on. Kui peer ootab aadressiidentiteeti, seadke localid-type address ja localid avalikule aadressile, mida peer näeb, seejärel kinnitage, et peer aktsepteerib seda väärtust identiteedina, mitte marsruutimise sihtpunktina. Kui peer ootab FQDN-i, kasutage localid-type fqdn ja nime, millega see konfigureeriti. Kontrollige, mida tegelikult saadeti, käsuga diagnose vpn ike gateway list, mis näitab lüüsi olekut ja kasutatavaid identifikaatoreid, mitte seda, mida kavatsesite sisestada. Ärge eeldage, et identiteeditüübi valik aktsepteerib suvalist mittekohalikku aadressi; kontrollige esmalt väljaande dokumenteeritud semantikat.

Samm 2: suunake UDP 500 ja 4500 seadmele edasi

Kolmas väärtus kuulub NAT-seadmele ja see on see, mille kontrollimise inimesed unustavad. Avalik lõpp-punkt peab suunama UDP 500 ja UDP 4500 FortiGate'ile edasi, sest NAT-T tuvastamine ja sellele järgnev kapseldatud ESP sõltuvad mõlemad nende portide saabumisest. See disain eeldab üks-ühele vastendust; ühe avaliku aadressi portidepõhine jagamine mitme peeri vahel on teistsugune topoloogia, millel on teistsugused piirid.

Kinnitage edasisuunamine püüdmisega, mitte lootusega: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 näitab, kas paketid saabuvad ja kas vastused väljuvad.

Google Cloud VPN dokumenteerib üks-ühele NAT-i koos NAT-T-ga kui toetatud lahendust NAT-i taga olevale peerile, ja see on piirang, mille vastu tuleb projekteerida, kui kaugem pool on Cloud VPN-i lüüs. Üks-mitmele või portidepõhine jagamine ei ole sama toetatud topoloogia ja ükski kohalik identiteedi häälestus ei muuda seda. Kui kaugem pool on mõni muu seade, määrab selle enda dokumentatsioon, mida see identiteedina aktsepteerib ja kas see talub tõlgitud peeri aadressi. Lugege seda enne kohaliku välja muutmist, sest kohalik pool ei saa läbi rääkida reeglit, mida kaugem pool ei rakenda.

Samm 3: kontrollige, mida faas 1 ei lahenda

NAT-i läbimine tõstab tunnelit, identiteedi kokkulepe otsustab, kas peer selle vastu võtab, ja sisemise prefiksi marsruutimine otsustab, mis tegelikult läbib. Õige kohalik ID ei suuda pakkuda puuduvat staatilist marsruuti ega puuduvat liiklusvalijat.

Seega kontrollige kihtide kaupa. get vpn ipsec tunnel details näitab, kas tunnel on üleval ja millised valijad läbi räägiti, ning konfigureeritud kaugema alamvõrgu ja läbiräägitud valija lahknevus on marsruutimisprobleem faasi 2 kostüümis. execute vpn ike gateway clear sunnib uuesti läbi rääkima, nii et testite praegust konfiguratsiooni, mitte enne teie viimast muudatust loodud sessiooni. Seejärel saatke liiklus kaugemas prefiksis asuvasse hosti ja kinnitage, et loendurid liiguvad, sest üleval olev ja mitte midagi läbi laskv tunnel näeb välja täpselt nagu töötav, kuni te kontrollite.

Hoidke kolm väärtust oma märkmetes ühes kohas: kohalik aadress, mis seadmel on, avalik lõpp-punkt, mida NAT-seade esitab, ja identiteedi string, mida peer ootab. Need muutuvad erinevatel põhjustel ja erinevatel aegadel.

NAT-seadme ümbernummerdamine ei ole põhjus FortiGate'i local-gw puudutada, ja identiteedi muutmine ei ole põhjus midagi ümber nummerdada. Kahe segamine on see, kuidas töötav tunnel mitteseotud hooldusakna ajal uuesti üles ehitatakse. Cloud VPN-i NAT-juhis on viide sellel poolel toetatud topoloogiale.

Test, mis selle otsustab, on igav ja kiire: püüdke välisliidesel, kinnitage, et UDP 500 ja 4500 saabuvad peerilt, kinnitage, et IKE-vahetuses olev identiteet vastab sellele, mida peer oli konfigureeritud ootama, seejärel kinnitage, et läbiräägitud valijad katavad alamvõrgud, mis teile olulised on. Kui esimene kontroll ebaõnnestub, on kahtlusalune NAT-seade. Kui teine ebaõnnestub, on süüdi identiteediväljad. Kui kolmas ebaõnnestub, ei olnud NAT ega identiteet kunagi probleem.