FortiGate-ը NAT-ի հետևում. local-gw, localid և հանրային IP

NAT-ի հետևում գտնվող FortiGate-ը կարող է ունենալ 10.0.0.2 իր WAN ինտերֆեյսի վրա, մինչդեռ ինտերնետը ներկայացնում է այն որպես 198.51.100.40, և երկու թվերն էլ իրական են։ Այն հասցեն, որին սարքը կապվում է, և այն ինքնությունը, որը նա ուղարկում է IKE նույնականացման ընթացքում, առանձին որոշումներ են՝ կայացված առանձին դաշտերում, առանձին լսարանի համար։ NAT-ը ճանապարհին վերագրում է արտաքին հասցեավորումը, բայց չի վերագրում նույնականացված ինքնությունը հեռավոր զուգընկերոջ սպասածին։ Այս ձևում փուլ 1-ի խափանումների մեծ մասը գալիս է ճիշտ արժեքը սխալ դաշտում դնելուց։

Երեք արժեք, երեք տեր

Սկսեք անվանել երեք արժեքները և յուրաքանչյուրի տիրոջը։ local-gw այն հասցեն է, որն օգտագործում է FortiGate-ը որպես IKE-ի աղբյուր իր արտաքին ինտերֆեյսի վրա, և այն պետք է լինի հասցե, որն իրականում պատկանում է սարքին։ Հանրային վերջնակետը NAT սարքի հասցեն է և պատկանում է նրան, ով կատարում է թարգմանությունը։ IKE ինքնությունը տող է, որը զուգընկերը համեմատում է իր կոնֆիգուրացիայի հետ, և ամենևին պարտադիր չէ, որ այն IP հասցե լինի։

Դաշտերի անունները բավական մոտ են փոխարինում հրահրելու համար, և դա է թակարդը։ localid և localid-type նկարագրում են նույնականացումը, local-gw նկարագրում է տեղական կապը։

Օրինակը տարբերությունը դարձնում է կոնկրետ։ FortiGate-ում բացեք config vpn ipsec phase1-interface, ապա set interface "wan1" և set local-gw 10.0.0.2 — հասցե, որը պատկանում է արկղին, և հենց դա է թույլ տալիս IKE սոկետին հաջողությամբ կապվել։ Թողեք local-gw -ը 0.0.0.0 -ի վրա, և կօգտագործվի ինտերֆեյսի հասցեն, ինչը սովորաբար նույնն է, բայց ավելի քիչ բացահայտ։ Մի սահմանեք local-gw -ը 198.51.100.40 -ի, որովհետև սարքը չի տիրում այդ հասցեին, և սոկետը չի կապվի դրան։ Երկու արժեք թղթի վրա հավասար ցույց տալը կոնֆիգուրացիա չէ։

Քայլ 1. ընտրեք այն ինքնությունը, որը կընդունի զուգընկերը

Հիմա ինքնությունը, որն այլ որոշում է։ set localid վերցնում է այն արժեքը, որը կհամեմատի զուգընկերը, և set localid-type ասում է FortiGate-ին, թե ինչպես այն մեկնաբանել՝ հասցե, FQDN, օգտվողի FQDN կամ բանալու ID։ auto -ով սարքը այն ածանցում է, սովորաբար ելքային ինտերֆեյսի հասցեից, ինչը հենց այն արժեքն է, որը NAT սարքը պատրաստվում է փոխել։

Հենց այդ ածանցումն է պատճառը, որ այս տոպոլոգիայում բացահայտ ինքնությունը կարևոր է։ Եթե զուգընկերը սպասում է հասցեային ինքնության, սահմանեք localid-type address և localid -ը այն հանրային հասցեին, որը կտեսնի զուգընկերը, ապա հաստատեք, որ զուգընկերը այդ արժեքն ընդունում է որպես ինքնություն, ոչ թե որպես երթուղման նպատակ։ Եթե զուգընկերը սպասում է FQDN-ի, օգտագործեք localid-type fqdn և այն անունը, որով այն կազմաձևվել է։ Ստուգեք, թե ինչ է իրականում ուղարկվել diagnose vpn ike gateway list -ով, որը ցույց է տալիս դարպասի վիճակը և օգտագործվող նույնացուցիչները, ոչ թե այն, ինչ դուք մտադիր էիք մուտքագրել։ Մի ենթադրեք, որ ինքնության տիպի ընտրանքը ընդունում է կամայական ոչ տեղական հասցե, նախ ստուգեք թողարկման փաստաթղթավորված իմաստաբանությունը։

Քայլ 2. փոխանցեք UDP 500 և 4500 պորտերը սարքին

Երրորդ արժեքը պատկանում է NAT սարքին, և հենց այն է, որ մարդիկ մոռանում են ստուգել։ Հանրային վերջնակետը պետք է փոխանցի UDP 500 և UDP 4500 պորտերը FortiGate-ին, որովհետև NAT-T հայտնաբերումը և դրան հաջորդող փաթեթավորված ESP-ը երկուսն էլ կախված են այդ պորտերի ժամանումից։ Այս նախագիծը ենթադրում է մեկ-մեկ քարտեզագրում. Մեկ հանրային հասցեի պորտային բաշխումը մի քանի զուգընկերների միջև այլ տոպոլոգիա է՝ այլ սահմաններով։

Հաստատեք փոխանցումը գրավմամբ, ոչ թե հույսով. diagnose sniffer packet any "udp port 500 or udp port 4500" 4 ցույց է տալիս՝ արդյոք փաթեթները գալիս են, և արդյոք պատասխանները դուրս գալիս։

Google Cloud VPN-ը փաստաթղթավորում է մեկ-մեկ NAT-ը NAT-T-ով որպես NAT-ի հետևում գտնվող զուգընկերոջ համար աջակցվող դասավորություն, և հենց այդ սահմանափակումն է, որի դեմ պետք է նախագծել, եթե հեռավոր ծայրը Cloud VPN դարպաս է։ Մեկ-շատ կամ պորտային բաշխումը նույն աջակցվող տոպոլոգիան չէ, և տեղական ինքնության ոչ մի կարգավորում դա չի փոխում։ Եթե հեռավոր կողմը այլ սարք է, նրա սեփական փաստաթղթերը սահմանում են, թե ինչ կընդունի որպես ինքնություն և արդյոք հանդուրժում է թարգմանված զուգընկերոջ հասցե։ Կարդացեք դա տեղական դաշտը փոխելուց առաջ, որովհետև տեղական կողմը չի կարող բանակցել մի կանոն, որը հեռավոր կողմը չի կիրառում։

Քայլ 3. ստուգեք, թե ինչ չի լուծում փուլ 1-ը

NAT-ի անցումը բարձրացնում է թունելը, ինքնության համաձայնությունը որոշում է՝ զուգընկերը կընդունի այն, թե ոչ, իսկ ներքին նախածանցի երթուղավորումը որոշում է, թե ինչ է իրականում անցնում։ Ճիշտ տեղական ID-ն չի կարող ապահովել բացակայող ստատիկ երթուղի կամ բացակայող երթևեկության ընտրիչ։

Այսպիսով ստուգեք շերտերով։ get vpn ipsec tunnel details ցույց է տալիս՝ արդյոք թունելը վերևում է և որ ընտրիչներն են բանակցվել, իսկ կազմաձևված հեռավոր ենթացանցի և բանակցված ընտրիչի անհամապատասխանությունը երթուղային խնդիր է փուլ 2-ի զգեստով։ execute vpn ike gateway clear ստիպում է վերաբանակցել, այնպես որ դուք ստուգում եք ընթացիկ կոնֆիգուրացիան, ոչ թե ձեր վերջին փոփոխությունից առաջ հաստատված սեսիան։ Այնուհետև երթևեկություն ուղարկեք հեռավոր նախածանցի հոսթին և հաստատեք, որ հաշվիչները շարժվում են, որովհետև վերևում գտնվող և ոչինչ չանցկացնող թունելը նույն տեսքն ունի, ինչ աշխատողը, մինչև չստուգեք։

Երեք արժեքները պահեք ձեր նշումների մեկ տեղում՝ տեղական հասցեն, որը պատկանում է սարքին, հանրային վերջնակետը, որը ներկայացնում է NAT սարքը, և ինքնության տողը, որը սպասում է զուգընկերը։ Դրանք փոխվում են տարբեր պատճառներով և տարբեր ժամանակներում։

NAT սարքի վերահամարակալումը պատճառ չէ դիպչելու FortiGate-ի local-gw -ին, և ինքնության փոփոխությունը պատճառ չէ որևէ բան վերահամարակալելու։ Երկուսը խառնելն այն է, թե ինչպես աշխատող թունելը վերակառուցվում է անկապ սպասարկման պատուհանի ընթացքում։ Cloud VPN-ի NAT ուղեցույց -ը հղումն է այդ կողմի աջակցվող տոպոլոգիայի համար։

Վճռորոշ թեստը ձանձրալի և արագ է. գրավեք արտաքին ինտերֆեյսի վրա, հաստատեք, որ UDP 500 և 4500-ը գալիս են զուգընկերոջց, հաստատեք, որ IKE փոխանակման ինքնությունը համապատասխանում է այն բանին, ինչի զուգընկերը կազմաձևված էր սպասելու, ապա հաստատեք, որ բանակցված ընտրիչները ծածկում են ձեզ հետաքրքրող ենթացանցերը։ Եթե առաջին ստուգումը ձախողվի, կասկածյալը NAT սարքն է։ Եթե երկրորդը, ապա ինքնության դաշտերն են։ Եթե երրորդը, ապա ոչ NAT-ը, ոչ ինքնությունը երբեք խնդիրը չեն եղել։