Hilsener! Velkommen til den femte leksjonen av kurset . På Vi har funnet ut hvordan sikkerhetspolitikk fungerer. Nå er det på tide å slippe lokale brukere ut på Internett. For å gjøre dette vil vi i denne leksjonen se på driften av NAT-mekanismen.
I tillegg til å slippe brukere til Internett, vil vi også se på en metode for publisering av interne tjenester. Under kuttet er en kort teori fra videoen, samt selve videoleksjonen.
NAT-teknologi (Network Address Translation) er en mekanisme for å konvertere IP-adresser til nettverkspakker. I Fortinet-termer er NAT delt inn i to typer: Source NAT og Destination NAT.
Navnene taler for seg selv - når du bruker Kilde NAT, endres kildeadressen, når du bruker Destination NAT, endres destinasjonsadressen.
I tillegg er det også flere alternativer for å sette opp NAT - Firewall Policy NAT og Central NAT.
Når du bruker det første alternativet, må kilde- og mål-NAT konfigureres for hver sikkerhetspolicy. I dette tilfellet bruker Source NAT enten IP-adressen til det utgående grensesnittet eller en forhåndskonfigurert IP-pool. Destinasjons-NAT bruker et forhåndskonfigurert objekt (den såkalte VIP - Virtual IP) som destinasjonsadresse.
Når du bruker sentral NAT, utføres kilde- og mål-NAT-konfigurasjonen for hele enheten (eller det virtuelle domenet) samtidig. I dette tilfellet gjelder NAT-innstillinger for alle policyer, avhengig av Source NAT og Destination NAT-reglene.
Kilde-NAT-regler er konfigurert i den sentrale kilde-NAT-policyen. Destinasjons-NAT konfigureres fra DNAT-menyen ved hjelp av IP-adresser.
I denne leksjonen vil vi kun vurdere brannmurpolicy NAT - som praksis viser, er dette konfigurasjonsalternativet mye mer vanlig enn sentral NAT.
Som jeg allerede sa, når du konfigurerer Firewall Policy Source NAT, er det to konfigurasjonsalternativer: å erstatte IP-adressen med adressen til det utgående grensesnittet, eller med en IP-adresse fra en forhåndskonfigurert pool av IP-adresser. Det ser omtrent ut som det som er vist i figuren nedenfor. Deretter vil jeg kort snakke om mulige bassenger, men i praksis vil vi kun vurdere alternativet med adressen til det utgående grensesnittet - i oppsettet vårt trenger vi ikke IP-adressepuljer.
En IP-pool definerer én eller flere IP-adresser som skal brukes som kildeadresse under en økt. Disse IP-adressene vil bli brukt i stedet for FortiGates utgående grensesnitt-IP-adresse.
Det er 4 typer IP-bassenger som kan konfigureres på FortiGate:
- Overlast
- En-til-en
- Fast havneområde
- Tildeling av havneblokk
Overbelastning er den viktigste IP-poolen. Den konverterer IP-adresser ved hjelp av et mange-til-en- eller mange-til-mange-skjema. Portoversettelse brukes også. Tenk på kretsen vist i figuren nedenfor. Vi har en pakke med definerte Kilde- og Destinasjonsfelt. Hvis den kommer under en brannmurpolicy som lar denne pakken få tilgang til det eksterne nettverket, brukes en NAT-regel på den. Som et resultat blir Kilde-feltet i denne pakken erstattet med en av IP-adressene som er spesifisert i IP-poolen.
En én til én-pool definerer også mange eksterne IP-adresser. Når en pakke faller inn under en brannmurpolicy med NAT-regelen aktivert, endres IP-adressen i kildefeltet til en av adressene som tilhører denne gruppen. Utskifting følger "først inn, først ut"-regelen. For å gjøre det klarere, la oss se på et eksempel.
En datamaskin på det lokale nettverket med IP-adressen 192.168.1.25 sender en pakke til det eksterne nettverket. Det faller inn under NAT-regelen, og kildefeltet endres til den første IP-adressen fra bassenget, i vårt tilfelle er det 83.235.123.5. Det er verdt å merke seg at når du bruker denne IP-poolen, brukes ikke portoversettelse. Hvis etter dette en datamaskin fra det samme lokale nettverket, med en adresse på for eksempel 192.168.1.35, sender en pakke til et eksternt nettverk og også faller inn under denne NAT-regelen, vil IP-adressen i kildefeltet til denne pakken endres til 83.235.123.6. Hvis det ikke er flere adresser igjen i bassenget, vil påfølgende tilkoblinger bli avvist. Det vil si at i dette tilfellet kan 4 datamaskiner falle inn under NAT-regelen vår samtidig.
Fixed Port Range kobler sammen interne og eksterne områder med IP-adresser. Portoversettelse er også deaktivert. Dette lar deg permanent knytte begynnelsen eller slutten av en pool av interne IP-adresser til begynnelsen eller slutten av en pool av eksterne IP-adresser. I eksemplet nedenfor er den interne adressepoolen 192.168.1.25 - 192.168.1.28 tilordnet den eksterne adressepoolen 83.235.123.5 - 83.235.125.8.
Port Block Allocation - denne IP-poolen brukes til å tildele en blokk med porter for IP-poolbrukere. I tillegg til selve IP-poolen, må også to parametere spesifiseres her - blokkstørrelsen og antall blokker tildelt for hver bruker.
La oss nå se på Destination NAT-teknologi. Den er basert på virtuelle IP-adresser (VIP). For pakker som faller inn under Destination NAT-reglene, endres IP-adressen i Destination-feltet: vanligvis endres den offentlige Internett-adressen til den private adressen til serveren. Virtuelle IP-adresser brukes i brannmurpolicyer som destinasjonsfeltet.
Standardtypen virtuelle IP-adresser er statisk NAT. Dette er en en-til-en korrespondanse mellom eksterne og interne adresser.
I stedet for statisk NAT, kan virtuelle adresser begrenses ved å videresende spesifikke porter. Knytt for eksempel tilkoblinger til en ekstern adresse på port 8080 med en tilkobling til en intern IP-adresse på port 80.
I eksemplet nedenfor prøver en datamaskin med adressen 172.17.10.25 å få tilgang til adressen 83.235.123.20 på port 80. Denne tilkoblingen faller inn under DNAT-regelen, så destinasjons-IP-adressen endres til 10.10.10.10.
Videoen diskuterer teorien og gir også praktiske eksempler på konfigurering av kilde- og mål-NAT.
I de neste leksjonene vil vi gå videre til å sikre brukersikkerhet på Internett. Nærmere bestemt vil neste leksjon diskutere funksjonaliteten til nettfiltrering og applikasjonskontroll. For ikke å gå glipp av det, følg oppdateringene på følgende kanaler:
Kilde: www.habr.com