Jibu la VPN kati ya maeneo halipiti kwenye handaki
Jibu linalokwepa handaki ni uamuzi wa uelekezaji upande wa mbali. Kagua jedwali la mwenyeji, vichaguzi na rp_filter, kisha chagua njia au NAT.
Nilikaa asubuhi nzima na handaki lililoinuka safi na kusafirisha trafiki kwa mwelekeo mmoja tu: tawi liliweza kufikia seva ya faili makao makuu, na kila muunganisho uliofunguliwa kutoka makao makuu kuelekea tawini ulikufa kwenye SYN ya kwanza. SA zilikuwa zinatumika, vihesabu vya handaki vilikuwa vikiongezeka, na kupeana mkono hakikuwa tatizo kamwe. Jibu lilikuwa likielekezwa mahali ambako handaki halifuniki, na chaguo hilo ni la upande wa mbali. VPN kati ya maeneo hubeba tu pakiti ambazo mwenyeji humkabidhi lango, na kila mwenyeji hufanya chaguo hilo kivyake, katika kila mwelekeo, kutoka kwenye jedwali lake la uelekezaji.
Mielekeo yote miwili huelekezwa kivyake
IP haihifadhi kumbukumbu yoyote ya mwelekeo wa mazungumzo. Kila mwenyeji anayetuma pakiti hufanya utafutaji wake wa kiambishi kirefu zaidi, huchagua hop moja inayofuata na kusahau uamuzi. Ombi na jibu ni pakiti mbili zisizohusiana ambazo kwa bahati ni za muunganisho mmoja, na handaki ni hop moja ambayo yeyote kati yao anaweza kuitumia au kutokuitumia. Hakuna kitu katika mabadilishano ya IKE kinachomfundisha seva ya mbali jinsi ya kufikia subnet yako; mazungumzo yanakubaliana tu ni viambishi vipi vinaweza kusimbwa.
Makubaliano hayo ni lango la pili. Kwenye strongSwan vichaguzi vya trafiki ni leftsubnet na rightsubnet, na pakiti ambayo chanzo au lengo lake liko nje ya jozi iliyokubaliwa haisimbwi, vyovyote jedwali la uelekezaji linavyosema. Kiambishi kinachoelekezwa ndani ya handaki lakini hakipo kwenye vichaguzi ni kushindwa kimya kwa upande mmoja: njia inaonekana sawa, pakiti bado inatoka wazi au hutupwa, na kumbukumbu ya charon pekee ndiyo inayolalamika.
Mwenyeji wa mbali hajui chochote kuhusu handaki lako
Ndani ya LAN ya mbali jibu ni pakiti ya kawaida iliyoelekezwa kwa mteja wako. Mwenyeji lengwa haoni kichwa chochote cha IPsec na hana sababu ya kupendelea lango la VPN; hutafuta kiambishi chako, hapati kitu mahususi zaidi ya njia yake ya msingi na huifuata. Ikiwa ya msingi inaelekeza kwenye ukuta wa moto mkuu, ukuta huo una njia ya kurudi ndani ya handaki au hauna. Bila kuwa nayo, unapata kutupwa kimya, ICMP unreachable, au jibu linalotoka kupitia kiolesura kinachoelekea intaneti na kufa.
Kiolesura cha pili kinatosha kuvunja hii hata njia ikiwepo. NAS yenye kiungo cha usimamizi kwenye VLAN nyingine, seva yenye uplink ya akiba, kanuni ya sera inayotuma masafa moja ya chanzo kwenye jedwali la pili: yoyote kati ya haya yanaweza kunasa jibu. Kwenye Linux, ip rule show na ip route show table all huonyesha kanuni na majedwali ambayo orodha ya msingi huficha.
Soma uamuzi kwenye mashine inayotuma jibu
Uliza kernel kabla ya kubadilisha chochote, na ipe anwani ya chanzo, kwa sababu kanuni zinazotegemea chanzo hubadilisha jibu.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"
Matokeo hutaja kiolesura cha kutoka na hop inayofuata. Ikiwa kiolesura si kile kinachoelekea lango la VPN, umepata hitilafu, na kazi iliyobaki ni kuchagua njia inapaswa kuwa wapi. Ping kutoka lango haithibitishi mengi hapa: hujibu kwa anwani ambayo mwenyeji wa mbali anaweza kuweka, si anwani ya laptop yako.
Kwenye Windows vipatanishi ni Find-NetRoute -RemoteIPAddress 10.10.5.10 kwa uamuzi na Get-NetRoute kwa jedwali. Njia iliyoongezwa kwa New-NetRoute na inayobeba metriki kubwa kuliko ya msingi hushindwa kimya, kwa hiyo soma safu ya metriki, si ingizo. Kisha thibitisha kwa pakiti: tcpdump -ni any "host 10.10.5.10 and tcp port 445" kwenye kiolesura cha LAN cha mbali huonyesha ombi, na kichujio kilekile upande wa handaki huonyesha kama jibu lilirudi. Ombi linaonekana bila jibu maana yake jibu lilipelekwa mahali pengine au lilitupwa; jibu kwenye kiolesura kibaya linakupa mkosaji kabla ya kugusa njia.
Wakati lango la seva si mwisho wa VPN
Maeneo mengi huweka ukuta wa moto kati ya seva na kiunganishi. Ukuta huo hupeleka jibu mbele, kwa hiyo unahitaji njia ya kiambishi cha mteja wako kuelekea lango la VPN, na sera ya upelekaji katika pande zote mbili. Vifaa vinavyohifadhi hali hufanya hali kuwa mbaya zaidi: ombi lilivuka ukuta kutoka kwa mwenyeji wa LAN ambaye ulikubali, jibu sasa linakuja kutoka mwelekeo mwingine, na ingizo la ufuatiliaji wa muunganisho halilingani tena, kwa hiyo pakiti hutupwa kama batili badala ya kukataliwa. Ndiyo sababu kumbukumbu ya sera inaonekana tupu wakati trafiki inapotea.
Lango lina kichujio chake cha pili. Uchujaji wa njia ya kurudi wa Linux hutupa pakiti ambazo chanzo chake hakifikiki kupitia kiolesura walikotokea, na hiyo ni sura kamili ya njia ya kurudi isiyolingana halali. mwongozo wa upelekaji wa strongSwan unahitaji net.ipv4.ip_forward na net.ipv4.conf.all.rp_filter iliyolegezwa kwa sababu hiyo. Thamani kali ya 1 kwenye lango lolote huvunja njia sahihi kimya, na nstat -az huonyesha kutupwa ikiwa unajua wapi kuangalia.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Elekeza au tafsiri, kisha thibitisha katika pande zote mbili
Marekebisho mawili hayalingani. Kuongeza njia huacha anwani ya mteja ikiwa sawa, kwa hiyo kanuni zinazotegemea chanzo, kumbukumbu za ukaguzi na programu zinazorekodi mpigaji zinaendelea kufanya kazi; gharama ni kwamba kila hop inayofanya uamuzi inahitaji njia, yaani mahali pengi pa kukosea. Kufunika kwenye lango la mbali hukaza njia ya kurudi hadi hop moja, kwa sababu jibu sasa limeelekezwa kwa lango lenyewe, na huficha ni mteja gani alifanya nini.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE
Ichague kwa makusudi: mara wateja wanapoonekana kama anwani ya lango, ACL zinazotegemea chanzo hazitawapambanua tena, na conntrack lazima ishike ramani ili jibu liandikwe tena ndani ya handaki. Ikiwa vichaguzi bado vinaondoa kiambishi cha mteja, NAT haibadilishi chochote, kwa sababu ombi halikuingia handakini kamwe.
Kabla ya kusema imerekebishwa, thibitisha mambo manne kwa mpangilio: njia kwenye mwenyeji anayetuma jibu, njia kwenye kila hop inayoipeleka, vichaguzi vinavyofunika viambishi vyote viwili, na kanda inayoonyesha jibu likiingia handakini na chanzo unachotarajia. Kisha rudia jaribio kutoka eneo lingine. Mwelekeo mmoja kupita ni muundo ulio wazi nusu, na mwelekeo wa pili kwa kawaida hushindwa kwa sababu tofauti na ile uliyoirekebisha hivi punde.