Nested na VPN: Aling Tunnel ang Nagdadala ng Panlabas na Koneksyon?

Dalawang kliyenteng VPN na tumatakbo nang sabay ay hindi lumilikha ng nested na tunnel; lumilikha sila ng dalawang tunnel at pagtatalo tungkol sa routing. May nested na tunnel kapag ang koneksyon ng panloob na kliyente sa sarili nitong server ay dala mismo ng panlabas na tunnel, at ito ay isang kaayusang sadyang ginagawa. Kapag tama, nakikita ng panloob na server ang address ng panlabas na server; kapag mali, tahimik na muling kumokonekta ang isang kliyente sa paligid ng isa pa. Tatlong kondisyon ang nagpapasya kung totoo o nagkataon lamang ang nesting.

Tatlong kondisyon ang nagpapasya sa nesting

Ang una ay kung aling dulo ang nangangailangan ng aling landas. Pangalanan ang address ng panloob na server, pangalanan ang address ng panlabas na server, at sabihin nang malinaw na maaabot lamang ang panloob na server sa pamamagitan ng panlabas na tunnel. Lahat ng iba ay sumusunod mula sa pangungusap na iyon, kabilang ang aling ruta ang nasa aling talahanayan.

Ang pangalawa ay kung nakikita mo ang landas sa bawat antas. Kung hindi mo matanong ang kernel kung aling ruta ang gagamitin ng isang partikular na destinasyon, hinuhulaan mo ang kadena mula sa huling palabas na IP, at iyon ang eksaktong ebidensyang hindi makakapaghiwalay ng nesting sa pagkakataon.

Ang pangatlo ay ano ang nangyayari kapag bumagsak ang panlabas na tunnel. Maaaring huminto kasama nito ang panloob na tunnel, muling kumonekta sa karaniwang network, o manatiling naharang hanggang bumalik ang panlabas na landas, at ang tatlo ay depensiblong patakaran. Hindi sila ang parehong patakaran, at ang default na gawi ng karamihan ng kliyente ay ang pangalawa. Ang kliyenteng muling kumokonekta sa sarili nitong dulo sa pisikal na network habang nagpapakita ng malusog na koneksyon ang pinakakaraniwang paraan kung paano tahimik na nagiging dalawang walang kaugnayang tunnel ang isang sinadyang kadena.

Unang kondisyon: aling dulo ang nangangailangan ng aling landas

ip route get 203.0.113.10 direktang sinasagot ang tanong na iyon: ipinapakita nito ang ruta, ang source address, at ang interface na gagamitin ng kernel para sa destinasyong iyon ngayon.

Patakbuhin ito para sa panloob na server bago magsimula ang panloob na kliyente at muli pagkatapos, at ihambing. Kung magbabago ang sagot mula sa pisikal na interface patungo sa interface ng panlabas na tunnel, totoo ang nesting sa sandaling iyon. Kung hindi ito magbabago, direktang kumokonekta ang panloob na kliyente, anuman ang sabihin ng panel. Ulitin ito para sa address ng panlabas na server, na kailangan pa ring lutasin sa pamamagitan ng pisikal na interface, dahil ang rutang humuhuli sa parehong dulo nang rekursibo ang sira na naglalabas sa makina mula sa network nang tuluyan.

Ikalawang kondisyon: suriin ang landas sa bawat antas

Ang pagpili ng ruta ay higit pa sa pangunahing talahanayan sa isang modernong kliyente. Maaaring magpadala ang mga patakaran ng patakaran ng mga markadong packet sa ibang talahanayan, maaaring iangkla ng kliyente ang socket nito sa isang interface, at may sariling mga talahanayan ang isang container o namespace. Ang ip rule at ip route show table all ang paraan para malaman kung alin sa mga mekanismong ito ang gumagana.

Ang kliyenteng naglalagay ng SO_MARK sa sariling socket, o naka-configure na umangkla sa isang partikular na device, ay lumalampas sa default na rutang inakala mong inayos mo. Ito ay isang tampok at hindi depekto, at nangangahulugan ito na ang tanging maaasahang pagsusuri ay ang tumatakbo sa parehong namespace ng kliyente. Kung tumatakbo ang mga kliyente sa mga container, patakbuhin ang mga pagsusuri sa loob ng mga container na iyon sa halip na sa host.

Ikatlong kondisyon: ano ang nangyayari kapag bumagsak ang panlabas na tunnel

Ang gawi kapag may sira ay nangangailangan ng desisyon, hindi ng default na halaga. Isulat kung ano ang dapat mangyari sa panloob na tunnel kapag nawala ang panlabas, pagkatapos ay gawin ang mga kliyente na gawin iyon.

Konkreto ang mga pagpipilian. Ang paghinto sa panloob na kliyente kapag nawala ang panlabas na landas ay nagbibigay ng malinis na kadena at malinaw na pagkagambala. Ang pagpayag nitong direktang kumonekta muli ay nagbibigay ng availability at tahimik na nag-aalis ng katangiang kung bakit itinayo ang kadena. Ang pagharang hanggang bumalik ang panlabas na landas ang pinakamahigpit at pinakainis patakbuhin, dahil ang bawat pagyanig ng panlabas na tunnel ay nagiging nakikitang insidente.

Subukan ang tatlo sa walang peligrong trapiko at sa sinadyang pagkabigo ng panlabas na tunnel, dahil ang pagbasa ng configuration ay hindi magsasabi sa iyo kung alin ang mayroon ka. Patayin ang panlabas na tunnel, obserbahan ang ginagawa ng panloob na kliyente, at suriin muli ang ruta habang down ito. Pagkatapos ay ibalik ang panlabas na tunnel at tiyakin na muling nabubuo ang kadena sa halip na iwan ang panloob na kliyente sa direktang landas na pinili nito sa pagitan.

Ano ang hindi ibinibigay ng kadena

Ang mga karagdagang antas ay nagdadagdag ng mga dulo, susi, at paraan ng pagkabigo; hindi sila nagdadagdag ng anumang garantiya ng anonymidad at hindi nila pinipigilan ang panlabas na operator na makita na may tunnel. Ang bawat pag-aangkin tungkol sa kung ano ang pinoprotektahan ng nesting ay dapat pangalanan ang tagamasid na pinoprotektahan nito.

Ang resulta ay isang maikling dokumento at hindi isang gumaganang koneksyon: aling dulo ang gumagamit ng aling landas, ano ang nangyayari sa panlabas na pagkabigo, at ang tatlong utos na nagpapakita ng kasalukuyang kalagayan. Ang dokumentasyon ng strongSwan tungkol sa pagpapasa ay kapaki-pakinabang na sanggunian kung paano ipinapasa ang trapiko ng tunnel sa pagitan ng mga interface sa isang Linux host. Patakbuhin muli ang mga pagsusuri pagkatapos ng bawat pag-update ng kliyente, dahil ang mga default na lumikha ng iyong kadena ay hindi kontrata. Ang nested na tunnel na hindi mo masuri ay tsismis na may ilaw ng estado.