Hairpin NAT. ինչու է VPN վերջնակետը ձախողվում ներսից

VPN սերվերը, որը պատասխանում է բջջային ցանցից, բայց ձախողվում է բազմոցից, սովորաբար վկայագրի խնդիր չէ։ LAN-ի ներսում գտնվող հաճախորդը երթուղիչից խնդրում է թարգմանել փաթեթ, որի նպատակակետը հենց երթուղիչի հանրային հասցեն է, այսինքն՝ փաթեթը պետք է դուրս գա և անմիջապես վերադառնա ներս։ Այդ մանևրը կոչվում է hairpinning, և շատ երթուղիչներ կամ ընդհանրապես չեն իրականացնում այն, կամ անում են միայն նշագծի միացման դեպքում։ Հենց դրսից արված թեստի հաջողությունն է շփոթեցնող, որովհետև այն ապացուցում է, որ լսողը և փոխանցման կանոնը կարգին են։

Փաթեթը դուրս է գալիս և վերադառնում ներս

Հետևեք փաթեթին։ Հաճախորդը լուծում է հանրային անունը, միանում է հանրային հասցեին, և երթուղիչի նպատակակետ NAT-ը վերագրում է նպատակակետը ներքին սերվերին։ Սերվերի պատասխանը հասցեագրված է հաճախորդի LAN հասցեին, ուստի այն վերադառնում է երթուղիչի LAN ինտերֆեյսով՝ երբեք չանցնելով այն NAT կանոնով, որը կվերաթարգմաներ աղբյուրը։

Այժմ հաճախորդը ստանում է փաթեթ այնպիսի հասցեից, ուր երբեք ոչինչ չի ուղարկել, և դեն է նետում այն։ Այդ անհամաչափությունն է ամբողջ խափանումը։

RFC 4787-ը նկարագրում է այն վարքը, որն ակնկալվում է NAT-ից այս դեպքում, և կարճ տարբերակն այն է, որ գործնականում այն ընտրովի է նույնիսկ այնտեղ, որտեղ տեսականորեն սահմանված է։ Որոշ երթուղիչներ այդ կարգավորումն անվանում են NAT loopback, մյուսները՝ hairpin NAT կամ NAT reflection, իսկ ոմանք ընդհանրապես ոչինչ չեն ցուցադրում։ Երթուղիչը, որում դա չկա, սխալ կազմաձևված չէ, այն անում է սովորականը, և ուղղումը պատկանում է այլ տեղ։ Չհանգեք ձախողված տեղական թեստից, թե հանրային փոխանցման կանոնը սխալ է։

Ստուգում 1. փորձարկեք երկու ուղիներն առանձին

LAN-ից դուրս միացեք նույն պրոֆիլով, որը կօգտագործեր իրական օգտատերը, և հաստատեք, որ սեսիան հաստատվում է։ Ներսից միացեք հանրային հասցեին նույն պրոֆիլով և գրանցեք ճշգրիտ սխալը և ժամը։

Ճշգրիտ տեղական թեստը պահում է հոսթի անունը և փոխարինում միայն հասցեն՝ curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ ուղարկում է հարցումը հանրային հասցեին՝ միաժամանակ ներկայացնելով ճիշտ սերվերի անունը։ Դա առանձնացնում է անվան լուծման խնդիրը թարգմանության խնդրից, որոնք հեշտ է շփոթել, երբ նույն անունը աշխատում է սրճարանից։ Նկատեք՝ հաճախորդը ձախողվում է TCP միացման ժամանակ, թե ավելի ուշ TLS-ում, որովհետև առաջինը ցույց է տալիս թարգմանությունը, իսկ երկրորդը՝ ինքնությունը։

Ստուգում 2. կարդացեք, թե ինչ է տեսնում սերվերը

Ամենաօգտակար դիտարկումը սերվերի տեսքն է։ Գործարկեք գրառում VPN հոսթի վրա՝ զտված հաճախորդի LAN հասցեով և երթուղիչի LAN հասցեով, ապա կրկնեք տեղական փորձը։ Եթե ոչինչ չի հասնում, փաթեթը չի վերապրել թարգմանությունը։

Եթե կապը գալիս է երթուղիչի LAN հասցեից, այլ ոչ թե հաճախորդի, ապա hairpinning է տեղի ունենում, և աղբյուրը վերագրվել է։ Սա աշխատող կազմաձև է, ոչ թե խափանում։

Ստուգում 3. ուղղեք առանց արտաքին ուղին դիպչելու

Կան երեք աջակցվող ձևեր՝ ազդեցության շառավղի աճման կարգով։ Ամենանեղը բաժանված DNS-ն է՝ հրապարակեք ներքին գրառում, որպեսզի նույն սերվերի անունը LAN-ի հաճախորդների համար լուծվի ներքին հասցեով, ինչը լիովին խուսափում է հանրային ուղուց։ Հաջորդը երթուղիչի փաստաթղթավորված loopback կամ reflection տարբերակի միացումն է, եթե այն կա, և դրա կիրառումը միայն այս ծառայության վրա։ Ամենալայնը source-NAT կանոնն է երթուղիչի վրա, որը վերագրում է LAN-ից եկող թրաֆիկը դեպի սերվեր, որպեսզի պատասխանը վերադառնա երթուղիչով, իսկ Linux երթուղիչում դա MASQUERADE կանոնն է POSTROUTING-ում, որը համընկնում է սերվերի հասցեի և պորտի հետ։ Երեքն էլ արտաքին ուղին անձեռնմխելի են թողնում, և հենց այդ հատկությունն է պահպանման ենթակա։

Մի ընդարձակեք անկապ պորտային փոխանցումը, որպեսզի տեղական ուղին նմանվի արտաքինին, և մի տեղափոխեք ծառայությունը այլ պորտ՝ խնդրից խուսափելու համար։ Երկու փոփոխություններն էլ փոխում են, թե ինչի կարող է հասնել արտաքին աշխարհը, որպեսզի ուղղեն մի բան, որ տեսնում է միայն ներքին աշխարհը։

Բաժանված DNS-ն ունի մեկ թակարդ, որն արժե անվանել։ Հոսթի անունը կամայական IP-ով փոխարինելը փոխում է, թե ինչ է վավերացնում հաճախորդը, ուստի ներքին գրառումը պետք է դեռ համապատասխանի վկայագրի անվանը։

Ստուգում 4. դրանից հետո ստուգեք երկու ուղիները

Կրկնեք արտաքին փորձը LAN-ից դուրս, կրկնեք ներքին փորձը նույն պրոֆիլով և հաստատեք, որ սերվերի մատյանը ցույց է տալիս երկու առանձին հաջող սեսիա, այլ ոչ թե մեկ հաջողություն և մեկ լռություն։ Ապա ստուգեք, որ մյուս հաճախորդները դեռ հասնում են լսողին, և որ մասնավոր ռեսուրսների երթուղիները անփոփոխ են։

Գրառումը կարճ պահեք՝ որ հասցեն օգտագործեց յուրաքանչյուր հաճախորդ, ինչ տեսավ սերվերը, և երեք ուղղումներից որն էր կիրառվել։ RFC 4787-ի hairpinning պահանջները այստեղ հղումն են, թե ինչ է ակնկալվում NAT-ից, և բացատրում են, թե ինչու առանց այդ հատկության երթուղիչը սովորաբար է վարվում։ Տեղական ձախողումը, որը արտաքին աշխարհը չի կարող վերարտադրել, թարգմանության հարց է, քանի դեռ հակառակը ապացուցված չէ, ուստի փորձարկեք այն որպես այդպիսին։