Thamani ya rejista ya NAT-T ya Windows: kagua topolojia kwanza

Muunganisho wa VPN wa Windows unashindikana, utafutaji hurejesha thamani ya rejista, na thamani hiyo huingizwa pamoja na kuwasha upya. Mfuatano huo wakati mwingine hufanya kazi na kamwe hauelezi chochote. Mpangilio unaozungumzwa hujibu swali moja kuhusu seva iko wapi kuhusiana na kifaa cha NAT, na hauna maana hadi ujue itifaki gani ilishindikana na katika hatua gani.

Thamani huchagua nini kwa kweli

AssumeUDPEncapsulationContextOnSendRule huamua ikiwa utekelezaji wa IPsec wa Windows utajaribu kuunda uhusiano na mwenzake aliye nyuma ya kifaa cha NAT. Thamani chaguo-msingi iliyoandikwa 0 hairuhusu kisa hicho, 1 huruhusu wakati seva ikiwa upande ulio nyuma ya NAT, na 2 inashughulikia pande zote mbili kutafsiriwa. Haya ni maelezo ya topolojia kuhusu nani yuko wapi.

Yakisomwa kama mfuatano, nambari hueleza tafsiri inayoongezeka, si utegemezi unaoongezeka. Kuweka 2 kwenye mtandao ambako hakuna kinachotafsiriwa hakufanyi muunganisho kuwa wa haraka au thabiti zaidi, na hakutengenezi kushindikana kwa uthibitishaji. Mwongozo wa NAT wa Microsoft kwa L2TP/IPsec unaandika sera na muktadha wake wa kihistoria wa jukwaa. Linganisha muktadha huo na toleo na jukumu la Windows unalotumia kwa kweli, kwa sababu hati iliyostahimili matoleo kadhaa si tamko kuhusu kila ujenzi wa sasa.

Oanisha topolojia kabla ya nambari

Chora njia na uweke alama za tafsiri: mteja yuko nyuma ya rauta ya nyumbani, seva iko nyuma ya kisawazisha mzigo au ukuta wa moto unaoandika upya anwani, na upande wowote uko nyuma ya tafsiri ya mtoa huduma usiyoidhibiti. Ni baada ya mchoro huo unawaweza kuamua ikiwa thamani inatumika, na kwa upande upi.

Dai kwamba matoleo ya sasa ya Windows Server huja tu na NAT traversal imezimwa ni pana mno kwa kuchukua hatua. Kilicho muhimu ni sera kwenye mfumo wako, topolojia mbele yake na mabadilishano yaliyoshindikana, kwa mpangilio huo. Ikiwa pande zote mbili zina anwani za umma, mpangilio si tatizo lako. Badala yake angalia pendekezo, cheti au akaunti, na uache rejista.

Kagua hatua ya kushindikana kwanza

L2TP/IPsec huzalisha angalau kushindikana tatu tofauti: mwenzake hafikiwi, ulinzi wa IPsec hauwezi kuanzishwa, na uthibitishaji wa mtumiaji wa PPP unakataliwa baada ya handaki kuwepo. Akaunti iliyokataliwa haiwezi kutengenezwa kwa kubadilisha sera ya NAT, na kutokulingana kwa mapendekezo hakuwezi kutengenezwa kwa kuwasha upya.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

Muda kuisha bila mjibu huashiria ufikikaji au uchujaji badala ya sera. Kukataliwa haraka na ujumbe wa pendekezo huashiria algoriti. Kushindikana baada ya handaki kupanda ni kwa hatua ya uthibitishaji, ambayo ni mmiliki mwingine na suluhisho lingine.

SSTP juu ya HTTPS na IKEv2 asilia zina kumbukumbu zao na vidhibiti vyao. Hakuna kinachokuwa kisa cha NAT-traversal kwa sababu tu kinaendeshwa pia kwenye Windows.

Fanya mabadiliko ukiwa na njia ya kurudi

Ikiwa sera iliyoandikwa na topolojia iliyozingatiwa zote zinahitaji, andika thamani ya awali, tumia mabadiliko kupitia usanidi unaosimamiwa badala ya script ya kila wasifu, na panga kuwasha upya. Kwenye seva inayosaidia mizigo mingine ya kazi, hii si hariri isiyo na madhara.

Kifaa cha NAT bado kinapaswa kubeba usafirishaji uliofungwa na trafiki ya kurudi. Thamani ya rejista haiundi sheria ya upelekaji, haiowiani mapendekezo na haithibitishi utambulisho, kwa hiyo muunganisho unaoanza kufanya kazi baada ya mabadiliko unaweza kufanya kazi kwa sababu tofauti kabisa. Jaribu tena itifaki asilia na topolojia asilia, kisha andika hatua ipi ilishindikana na kwa nini ilitarajiwa thamani hiyo kuishughulikia. Sentensi hiyo ndiyo inayobadilisha uvumi wa mtandao kuwa usanidi unaoweza kuutetea.