Kwa nini GRE na ESP hushindwa kupitia lango la NAT la AWS
Lango la NAT linalosimamiwa husambaza TCP, UDP na ICMP pekee. Angalia kwa nini sheria ya ruhusa haiwezi kubeba GRE au ESP asilia, na nini cha kubadilisha badala yake.
Tuneli inashindwa, kikundi cha usalama tayari kinaruhusu trafiki yote, na hitimisho ni kwamba AWS inazuia VPN. Haizuii chochote. Lango la NAT linalosimamiwa husambaza seti iliyoandikwa ya itifaki za nje, na GRE asilia au ESP asilia hazimo, kwa hivyo hakuna sheria unayoongeza itakayofanya lango kuzibeba. Sheria ya ruhusa na uwezo wa usafirishaji ni mambo mawili tofauti, na mmoja tu kati yao uko mikononi mwako kubadilisha.
Seti ya sheria si seti ya itifaki
Kikundi cha usalama huamua ni trafiki gani inaruhusiwa kuondoka kwenye kipengele. Lango la NAT huamua nini linaweza kutafsiri na kusambaza. Wakati kikomo cha pili kinatumika, sheria inayoruhusu hutoa ishara ile ile ambayo watu huisoma vibaya kama tatizo la firewall: pakiti huondoka kwenye kipengele, ubadilishanaji wa udhibiti unaweza hata kukamilika, na hakuna kinachofika kwa mwenzake.
AWS vipimo vya itifaki za lango la NAT vinaorodhesha TCP, UDP na ICMP kwa huduma inayosimamiwa. Hiyo ni seti yote inayotumika. Sheria ya ruhusa kwa itifaki nyingine ya IP haiwezi kuipanua, kwa sababu sheria hutathminiwa muda mrefu kabla ya kufikia njia ya usambazaji ya lango.
Tofauti hii ni muhimu kwa sababu hitilafu hizo mbili zinaonekana sawa kutoka kwa mteja na zina marekebisho tofauti kabisa.
PPTP inaonyesha kwa nini jaribio la bandari husema uongo
PPTP ni mfano wa zamani ulio wazi zaidi wa ukaguzi wa bandari ambao hauthibitishi chochote. Hufungua muunganisho wa udhibiti wa TCP kwenye bandari 1723 kisha husafirisha data ya tuneli kupitia GRE, ambayo ni itifaki ya IP 47. Itifaki 47 si bandari ya TCP 47, na namba hizi mbili hazina uhusiano wowote isipokuwa kushirikiana tarakimu.
Mwendeshaji anayefanya jaribio la muunganisho hadi 1723 na kuona makubaliano ya mkono yaliyokamilika huhitimisha kuwa njia inafanya kazi. Kisha kituo cha data hakiwahi kupitisha hata pakiti moja, kwa sababu lango halina msaada wowote wa GRE wa kutoa. Hii ni tafsiri ya mahitaji ya itifaki ya zamani, si ushauri wa kusambaza PPTP, ambayo imepitwa na wakati kwa miaka.
Hoja hiyo hiyo inatumika kwa itifaki yoyote ambayo kituo chake cha udhibiti ni TCP au UDP wakati njia yake ya data haiko hivyo.
IPsec huendelea kuishi kama UDP pekee
IPsec ni kisa ambapo jibu ni la masharti badala ya hapana moja kwa moja. AWS inaandika upitishaji wa NAT kama mpangilio unaotumika kwa IPsec kupitia lango la NAT. NAT-T ikijadiliwa, ESP hufungwa ndani ya UDP na lango huona UDP ya kawaida badala ya itifaki 50.
Kuruhusu UDP 4500 hakuifanyi ncha za mwisho kutumia upitishaji wa NAT. Hukuruhusu pakiti tu ikiwa tayari zimeundwa hivyo. Thibitisha kutoka matokeo ya majadiliano ya mteja mwenyewe ni ufungashaji upi uliochaguliwa, na thibitisha upande unaopokea kwamba mwenzake alikubali. Ncha mbili za mwisho zilizosanidiwa kwa ESP asilia zitaendelea kutuma ESP asilia, vyovyote seti ya sheria inavyosema.
VPN inayotegemea TCP au UDP inafaa seti iliyoandikwa ya usafirishaji na bado inaweza kushindwa kwa sababu za uelekezaji, uchujaji au uthibitishaji. Kufaa seti ni lazima, si kutosha.
Kagua njia kabla ya kupanua sera
Thibitisha njia halisi ya subneti ya mzigo wa kazi na utambulisho wa hop yake inayofuata kwanza. Njia ya moja kwa moja ya umma, kipengele cha NAT, lango la NAT linalosimamiwa na njia ya faragha kupitia lango la usafirishaji ni miundo minne tofauti, na mmoja tu kati yao ni huduma inayosimamiwa iliyoelezwa hapa.
Kisha rekodi ncha ya mwisho iliyojaribiwa, familia ya anwani, itifaki ya nje na bandari pale itifaki inapo kuwa nayo. Tumia uchunguzi wa mteja na uchunguzi wa mtiririko wa mmiliki wa mtandao badala ya ombi la kivinjari lililofanikiwa, ambalo huthibitisha tu kwamba TCP na UDP zinafanya kazi. Baada ya hapo, kagua kikundi cha usalama, ACL ya subneti, firewall ya mgeni na sera ya huduma kwa pande zote mbili za mtiririko.
Usifungue trafiki yote ili kufidia usafirishaji ambao huduma haiwezi kuubeba. Mabadiliko ya sheria hayatarekebisha hilo, na yataendelea kuishi baada ya tukio.
Wakati usafirishaji haufai
Ikiwa itifaki ya nje iko nje ya seti inayotumika, marekebisho ni ya usanifu: chagua usafirishaji ambao njia inaweza kuubeba, au hamishia utokeaji kwenye kitu kinachobeba kile unachohitaji. OpenVPN juu ya UDP, WireGuard juu ya UDP na tuneli zinazotegemea TLS zote zinafaa seti iliyoandikwa. Kipengele cha NAT kinachosimamiwa na mteja ni chaguo wakati itifaki maalum lazima ipite na gharama ya uendeshaji wa kuisimamia inakubalika.
Kupangisha seva ya VPN ya ndani ni tatizo tofauti lenye jibu tofauti. Lango la NAT hutoa tafsiri ya kutoka na hakuna usambazaji wa jumla wa bandari za ndani, kwa hivyo seva iliyo nyuma yake inahitaji kiingilio chake cha umma kilichoidhinishwa kilichoundwa kwa masharti yake.
Mpangilio wa kazi: taja itifaki ya nje, thibitisha hop inayofuata, linganisha na seti iliyoandikwa, kisha badilisha usanifu au usafirishaji. Namba nyingine ya bandari haiwezi kugeuza GRE kuwa TCP, na sheria moja zaidi inayoruhusu haiwezi kugeuza ubadilishanaji wa udhibiti uliokamilika kuwa kituo cha data kinachofanya kazi.