FortiGate efter NAT: local-gw, localid en it iepenbiere IP
In FortiGate efter NAT hat in lokaal adres, in oerset iepenbier einpunt en in IKE-identiteit. FortiOS hâldt se yn fjilden dy't net útwikselber binne.
In FortiGate efter NAT kin 10.0.0.2 besitte op syn WAN-ynterface, wylst it ynternet it as 198.51.100.40 presintearret, en beide nûmers binne echt. It adres dêr't it apparaat oan bynt en de identiteit dy't it by IKE-autentikaasje stjoert, binne aparte karren, makke yn aparte fjilden, foar apart publyk. NAT skriuwt de bûtenste adressaasje ûnderweis oer; it skriuwt in autentisearre identiteit net oer yn wat de fiere peer ferwachtet. De measte flaters fan faze 1 yn dizze foarm komme fan it setten fan de juste wearde yn it ferkearde fjild.
Trije wearden, trije eigners
Begjin mei it beneamen fan de trije wearden en wa't elk hat. local-gw is it adres dat FortiGate brûkt as boarne foar IKE op syn eksterne ynterface, en it moat in adres wêze dat it apparaat echt hat. It iepenbiere einpunt is it adres fan it NAT-apparaat, en it is fan dejinge dy't de oersetting docht. De IKE-identiteit is in tekenrige dy't de peer mei syn eigen konfiguraasje ferliket, en it hoech hielendal gjin IP-adres te wêzen.
De fjildnammen binne ticht genôch byinoar om ferfanging út te noegjen, en dat is de falstrik. localid en localid-type beskriuwe identifikaasje; local-gw beskriuwt lokale bining.
In foarbyld makket it ferskil konkreet. Iepenje op 'e FortiGate config vpn ipsec phase1-interface, dan set interface "wan1" en set local-gw 10.0.0.2 — in adres dat de kast hat, en dat is wat de IKE-socket slagje lit by it binen. Lit local-gw op 0.0.0.0 en it ynterface-adres wurdt brûkt, wat meastentiids itselde is mar minder eksplisyt. Set local-gw net op 198.51.100.40, want it apparaat hat dat adres net en de socket sil der net oan bine. Twa wearden op papier gelyk lykje litte is gjin konfiguraasje.
Stap 1: kies de identiteit dy't de peer akseptearret
No de identiteit, dat is in oare beslissing. set localid nimt de wearde dy't de peer ferliket, en set localid-type fertelt de FortiGate hoe't dy te ynterpretearjen: in adres, in FQDN, in brûkers-FQDN of in kaai-ID. Mei auto liedt it apparaat it ôf, meastentiids fan it adres fan 'e útgeande ynterface, dat krekt de wearde is dy't in NAT-apparaat op it punt stiet te feroarjen.
Dy ôflieding is de reden wêrom't in eksplisite identiteit yn dizze topology fan belang is. As de peer in adresidentiteit ferwachtet, set localid-type address en localid op it iepenbiere adres dat de peer sjocht, en befêstigje dan dat de peer dy wearde as identiteit akseptearret en net as rûte-doel. As de peer in FQDN ferwachtet, brûk localid-type fqdn en de namme dêr't it mei konfigurearre is. Kontrolearje wat der eins stjoerd is mei diagnose vpn ike gateway list, dy't de steat fan 'e gateway en de brûkte identifikaasjes sjen lit, net wat jo fan doel wiene te typen. Nim net oan dat in identiteitstype-opsje in willekeurich net-lokaal adres akseptearret; kontrolearje earst de dokumintearre semantyk fan 'e útjefte.
Stap 2: stjoer UDP 500 en 4500 troch nei it apparaat
De tredde wearde heart by it NAT-apparaat, en dat is dejinge dy't minsken ferjitte te kontrolearjen. It iepenbiere einpunt moat UDP 500 en UDP 4500 trochstjoere nei de FortiGate, want NAT-T-deteksje en de ynkapsulearre ESP dy't folget binne beide ôfhinklik fan it oankommen fan dy poarten. Dit ûntwerp ferûnderstelt in ien-op-ien-mapping; it dielen fan ien iepenbier adres op poarten tusken ferskate peers is in oare topology mei oare grinzen.
Befêstigje it trochstjoeren mei in opname, net mei hoop: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 lit sjen oft pakketten oankomme en oft antwurden fuortgeane.
Google Cloud VPN dokumintearret ien-op-ien NAT mei NAT-T as de stipe regeling foar in peer efter NAT, en dat is de beheining dêr't jo tsjin ûntwerpe moatte as de fiere ein in Cloud VPN-gateway is. Ien-op-folle of op poarten dielen is net deselde stipe topology, en gjin inkele lokale identiteitsôfstelling feroaret dat. As de fiere kant in oar apparaat is, bepaalt syn eigen dokumintaasje wat it as identiteit akseptearret en oft it in oerset peer-adres tolerearret. Lês dat foardat jo in lokaal fjild feroarje, want de lokale kant kin gjin regel ûnderhannelje dy't de fiere kant net ymplementearret.
Stap 3: kontrolearje wat faze 1 net oplost
NAT-trochgong krijt de tunnel omheech, identiteitsoerienstimming beslút oft de peer him akseptearret, en routing fan it binnenste prefiks beslút wat der eins oer giet. In krekte lokale ID kin gjin ûntbrekkende statyske rûte of ûntbrekkende ferkiersselektor leverje.
Ferifiearje dus yn lagen. get vpn ipsec tunnel details lit sjen oft de tunnel omheech is en hokker selektors ûnderhannele binne, en in ôfwiking tusken it konfigurearre fiere subnet en de ûnderhannele selektor is in routingprobleem yn in faze 2-kostúm. execute vpn ike gateway clear twingt in nije ûnderhanneling, dat jo testen de hjoeddeiske konfiguraasje en net in sesje dy't foar jo lêste feroaring oprjochte is. Stjoer dan ferkear nei in host yn it fiere prefiks en befêstigje dat de tellers bewege, want in tunnel dy't omheech is en neat trochlit sjocht der itselde út as in wurkjende oant jo kontrolearje.
Hâld de trije wearden op ien plak yn jo notysjes: it lokale adres dat it apparaat hat, it iepenbiere einpunt dat it NAT-apparaat presintearret, en de identiteitstekst dy't de peer ferwachtet. Se feroarje om ferskate redenen en op ferskate tiden.
It fernijen fan 'e nûmering fan it NAT-apparaat is gjin reden om local-gw fan 'e FortiGate oan te reitsjen, en in identiteitsferoaring is gjin reden om eat opnij te nûmerjen. It mingen fan beide is hoe't in wurkjende tunnel by in net-relatearre ûnderhâldsfinsters wer opboud wurdt. De Cloud VPN NAT-lieding is de referinsje foar de stipe topology oan dy kant.
De test dy't it beslist is saai en fluch: meitsje in opname op 'e eksterne ynterface, befêstigje dat UDP 500 en 4500 fan 'e peer ôf komme, befêstigje dat de identiteit yn 'e IKE-útwikseling oerienkomt mei wat de peer konfigurearre wie om te ferwachtsjen, en befêstigje dan dat de ûnderhannele selektors de subnetten dekke dy't jo oan geane. As de earste kontrôle mislearret, is it NAT-apparaat de fertochte. As de twadde mislearret, binne it de identiteitsfjilden. As de tredde mislearret, wiene noch NAT noch identiteit ea it probleem.