Mtandao wa VM wa NAT au bridged: upi unaobeba trafiki ya VPN?

Bridged na NAT si njia mbili za kuunganisha mgeni yuleyule kwenye VPN yako; zinaamua nani anamiliki pakiti za mgeni kabla handaki yoyote haijaingia. Katika hali ya NAT, hypervisor huandika upya trafiki ya mgeni na kuitoa kutoka msimbo wa upande wa mwenyeji, kwa hivyo mgeni hufuata njia yoyote ambayo mwenyeji anaipa msimbo huo. Katika hali ya bridged, mgeni hupata utambulisho wake wa safu ya kiungo kwenye sehemu halisi na huchagua lango lake la msingi, jambo linalofanya handaki la mwenyeji lisijali kwake, isipokuwa kipanga njia cha LAN ndicho kinachofanya handaki. Niliacha kuchukulia VM kama kitu kilicho kwenye VPN na nikaanza kuchukulia hilo kama swali la wapi njia ya msingi ya mgeni huyo inaelekea. Jaribio lililo hapa chini huchukua dakika chache kwa kila hali na huamua jambo bila kubahatisha.

NAT huweka mgeni nyuma ya msimbo wa hypervisor, ambako njia za mwenyeji zinatumika

Katika VirtualBox, mgeni wa NAT hukaa kwenye 10.0.2.0/24 akiwa na lango la mtandao wa kidhahania la 10.0.2.2, proksi ya DNS ya 10.0.2.3, na hana njia yake mwenyewe kuelekea mtandao halisi. Pakiti zinazotoka huchukuliwa na mashine ya NAT, huandikwa upya ili chanzo kiwe mwenyeji, na hupewa staki ya IP ya mwenyeji. Kutoka hapo trafiki ya mgeni ni mtiririko wa mwenyeji, na utafutaji wa njia hufanywa kwa mwisho: mteja aliye na handaki kamili anayeweka 0.0.0.0/1 na 128.0.0.0/1 kwenye mwenyeji huikamata bila kujua kamwe kuwa VM ipo. Sura ya Oracle kuhusu mitandao katika VirtualBox huorodhesha thamani hizi za msingi ikiwa unataka kuthibitisha anwani kwenye build yako.

Mtandao wa msingi wa libvirt hufika mahali pale pale kutoka 192.168.122.0/24, ambako dnsmasq hutoa ukodishaji na mwenyeji huficha subnet, kwa hivyo pakiti za mgeni hurudi tena kwenye uamuzi wa njia wa mwenyeji. Isipokuwa ni mteja anayechagua trafiki kwa mchakato badala ya kwa njia. Ikiwa orodha ya handaki iliyogawanywa ina kivinjari chako pekee, mashine ya NAT haimo kwenye orodha hiyo, na mgeni hutoka kwenye mashine bila handaki wakati kivinjari cha mwenyeji bado kinaonekana kufunikwa. Subnet moja, matokeo kinyume.

Bridged humpa mgeni nafasi yake mwenyewe kwenye LAN halisi

Mgeni wa bridged hupewa NIC ya kidhahania iliyounganishwa na adapta halisi, hupata anwani yake ya MAC, na huchukua ukodishaji wa DHCP kutoka mtandao halisi. Lango lake la msingi ni kipanga njia cha LAN, si hypervisor, na fremu zake huenda kwenye waya kupitia adapta hiyo. Njia za handaki za mwenyeji ziko kwenye jedwali la mwenyeji na hazishauriwi kamwe, kwa sababu fremu za mgeni haziingii kamwe kwenye staki ya IP ya mwenyeji.

Hilo hukata pande zote mbili. Uvinjari wa mDNS na SMB huanza kufanya kazi kwa sababu mgeni anaona trafiki ya matangazo ya LAN, na mgeni anafikika kutoka mashine nyingine kwenye sehemu hiyo bila firewall ya mwenyeji katikati. Bridging pia si njia ya kusukuma mgeni kupitia handaki lililopo: kuunganisha VM kwenye kiolesura cha WireGuard au OpenVPN cha mwenyeji si kitu ambacho VirtualBox au libvirt hufanya kwa ajili yako. Ikiwa mgeni wa bridged lazima apitishwe kwenye handaki, handaki lazima liishie mahali fulani kwenye LAN hiyo.

Jaribio linalomaliza mjadala

Endesha ukaguzi uleule katika hali zote mbili na uandike majibu:

• Kwenye mwenyeji, curl -s https://ifconfig.me hutoa anwani ya umma ya v4.
• Kwenye mgeni, amri ileile, pamoja na ip route kwenye Linux au Get-NetRoute -DestinationPrefix 0.0.0.0/0 kwenye Windows kwa lango la msingi.
• Utambulisho wa kitatuzi: resolvectl status au cat /etc/resolv.conf kwenye mgeni, kuona kama inaelekeza kwenye 10.0.2.3 au kwenye seva ya LAN.
• Familia ya anwani: ip -6 addr show scope global na ombi moja la v6, kwa sababu handaki la v4 halisemi chochote kuhusu anwani ya global v6 ambayo mgeni anaweza kuwa nayo.

Anwani za umma zinazolingana humaanisha kuwa mgeni yuko kwenye njia ya mwenyeji. Anwani ya mgeni inayolingana na matokeo ya kawaida ya LAN humaanisha kuwa hayuko. Hatua ambayo watu huiruka ni udhibiti: shusha handaki la mwenyeji kisha urudie ombi la mgeni. Ikiwa mgeni anaendelea kuvinjari, hakuwahi kutegemea handaki la mwenyeji, jina la hali lisiseme nini. Katika hali ya NAT, mgeni anapaswa kupoteza intaneti handaki la mwenyeji likishushwa, isipokuwa mteja amesanidiwa kuruhusu trafiki nje ya handaki, jambo ambalo yenyewe linafaa kujulikana.

Ishara mbili husema uongo. Ping iliyofanikiwa huthibitisha ufikikaji, si njia ya kutoka. Na DNS inaweza kujibiwa na proksi ya 10.0.2.3 kupitia kitatuzi cha mwenyeji wakati TCP inachukua njia nyingine, na hivyo ndivyo unavyopata ukurasa unaopakia na kuingia ambako hakukamiliki kamwe.

Hali ipi inafaa kazi

Hali ni uamuzi wa njia, kwa hivyo ichague kwa mahitaji badala ya mazoea:

Mstari wa kwanza ndipo watu hunaswa: NAT pamoja na mteja wa handaki kamili kwenye mwenyeji humfunika mgeni kweli, lakini tu wakati mteja anapitisha kwa njia na kiungo cha juu cha mwenyeji ni handaki hilo. Hamishia mteja kwenye orodha ya ruhusa ya kivinjari pekee na ufunikaji hutoweka bila kosa lolote mahali popote. Mstari wa nne ni kosa la kinyume, mgeni aliyebridged kwa urahisi ambaye kwa utulivu huanza kujibu SMB au SSH kwenye LAN ya ofisi.

Hitilafu zinazolaumiwa VPN

Kwenye Windows, tafsiri ya NAT huendeshwa ndani ya mchakato wa VM wa VirtualBox, kwa hivyo mteja wa kila programu anahitaji picha hiyo hasa kwenye orodha yake, si kanuni ya jumla kwa mashine za kidhahania. Uboreshaji wa mteja unapojenga upya orodha ya michakato inayoruhusiwa, wageni wa NAT hupoteza ufunikaji kwanza, na ripoti husomeka kama VM inayofikia LAN lakini si intaneti wakati mwenyeji yuko sawa.

Bridging kwenda Wi-Fi ni kesi nyingine ya kawaida. Vituo vya ufikiaji mara chache husambaza fremu zilizo na MAC ya chanzo ya kigeni, kwa hivyo daraja kwenye wlan0 ama hushindwa papo hapo ama hufanya kazi hadi utengaji wa wateja kwenye AP uanze kuiondoa. VirtualBox bado itatoa adapta isiyo na waya kwenye orodha. Ikiwa mwenyeji yuko kwenye Wi-Fi na mgeni lazima awe bridged, panga jaribio badala ya kudhani.

MTU ni ya tatu. Mgeni wa bridged huhifadhi MTU ya LAN ya baiti 1500, na ikiwa anaendesha mteja wake wa WireGuard kwenye 1420, mikono mikubwa ya TLS hukwama wakati maombi madogo hufanikiwa. Chini ya NAT, MTU ya handaki la mwenyeji ni tatizo la mwenyeji, lakini mgeni bado anaamini 1500, na UDP yenye biti ya don't-fragment huanguka kwenye shimo jeusi vivyo hivyo.

Andika hali kisha ukague tena baada ya mabadiliko yoyote ya adapta

Rekodi hali, kiolesura cha mwenyeji kinachotumiwa na daraja, lango la msingi la mgeni, kitatuzi chake, na anwani zake za kutoka za v4 na v6. Rekodi hiyo ndiyo inayofanya hitilafu ijayo kuwa rahisi: kompyuta ya mkononi inapohama kutoka dock kwenda Wi-Fi, mgeni wa bridged hufuata daraja kwenda adapta nyingine halisi na anaweza kukodisha tena kwenye subnet nyingine, wakati mgeni wa NAT huhifadhi anwani yake ya 10.0.2.x na kurithi kimyakimya kiungo kingine cha juu.

Kabla ya kufunga tikiti, thibitisha kila moja ya haya:

• Anwani ya kutoka ya mgeni inatofautiana na anwani ya kutoka ya mwenyeji, kwa hivyo hayuko kwenye handaki la mwenyeji.
• Kitatuzi ni proksi ya 10.0.2.3 au seva ya LAN, na unajua ni ipi iliyojibu.
• Hakuna anwani ya global v6 kwenye mgeni ikiwa muundo wa handaki ni wa v4 pekee.
• Handaki la mwenyeji likishushwa, mgeni huacha kuvinjari, au sasa unajua hakuwahi kutegemea hilo.
• Mgeni haoni trafiki ya matangazo ya LAN ambayo hana sababu ya kuiona.