Je, VM yako inatumia VPN ya mwenyeji? Ijaribu kutoka ndani ya mgeni

Unakagua IP ya umma ya mwenyeji, inaonyesha VPN, na unahitimisha kuwa VM imefunikwa. Hitimisho hilo haliungwi mkono na jaribio hili. Mgeni ana jedwali lake la uelekezaji, kitatuzi chake na violesura vyake, na anwani ya kutoka ya mwenyeji haisemi chochote kuhusu vyote hivyo.

Jaribio lazima lifanyike ndani ya mgeni, na lazima litaje kilichopimwa.

Anza kutoka ndani ya mgeni, sio kwenye kivinjari cha mwenyeji

Kwanza rekodi hali ya mtandao ya hypervisor: NAT, bridged, host-only au macvtap. Katika hali ya NAT mwenyeji huelekeza trafiki ya mgeni, kwa hivyo tunnel ya mwenyeji inaweza kutumika au kutotumika kulingana na jinsi mteja anavyoweka njia. Katika hali ya bridged mgeni ni mshiriki sawa kwenye LAN ya kimwili na tunnel ya mwenyeji haihusiki. Hali hizi mbili hutoa majibu kinyume kutoka kwa usanidi mmoja wa mwenyeji.

Andika hali hiyo kabla ya kubadilisha chochote, kwa sababu ndiyo inayoamua maana ya matokeo.

Fanya ombi moja ambalo unajua mahali panakokwenda

Tumia ombi lisilo na madhara kwa huduma inayoripoti anwani ya chanzo iliyoiona. Kisha angalia uamuzi wa uelekezaji wa mgeni mwenyewe kwa mahali hapo: ip route get 203.0.113.5 huchapisha violesura na lango ambavyo mgeni atavitumia.

Ikiwa violesura ni NIC ya kawaida ya mgeni, trafiki haipiti kwenye tunnel ndani ya mgeni.

Adapta ya pili, mpangilio wa proksi au mteja wa VPN upande wa mgeni unaweza kubadilisha jibu kwa programu moja na sio nyingine. Jaribu programu unayojali kweli, sio ombi la jumla kutoka kwenye shell.

Angalia kitatuzi kwa tofauti

Anwani ya kutoka iliyobadilika haikwambii ni kitatuzi kipi kilishughulikia jina hilo la mwenyeji. Uliza jina hilo waziwazi kwa chombo kinacholingana na jukwaa, na andika ni seva ipi ilijibu. Split DNS inamaanisha kuwa swali la kitatuzi na swali la uelekezaji zina majibu tofauti.

Hizo mbili zinaweza kutofautiana kwa mwelekeo wowote, na tofauti hiyo mara nyingi ndiyo hitilafu halisi.

Kwenye mwenyeji wa systemd, resolvectl query hutaja violesura na seva ya DNS iliyo nyuma ya jibu. Mipangilio ya zamani huonyesha seva kwenye matokeo ya dig. Kwa vyovyote vile, hoja ni kuona ni seva ipi ilijibu, sio tu kama jibu lilifika.

Jaribu sera ya kushindwa, sio mafanikio tu

Ikiwa hitaji ni kwamba hakuna trafiki inayotoka nje ya tunnel, ombi lililofanikiwa halithibitishi chochote. Tumia jaribio la kushindwa linalodhibitiwa linaloungwa mkono na mteja: simamisha tunnel kwa njia inayoungwa mkono na uone kama ombi jipya la mgeni limezuiwa. Usidhani kwamba kill switch ya mteja wa mwenyeji inashughulikia kila mpangilio wa upelekaji wa mtandao wa kawaida. Wigo wake ulioandikwa ndio kitu pekee unachoweza kutegemea.

Mgeni anayerudi kwenye NIC ya kimwili tunnel inapoanguka anafanya hasa kile ambacho hali ya NAT inaruhusu.

Rekodi hali na wigo

Andika hali ya hypervisor, violesura na njia ya mgeni, kitatuzi, na programu uliyojaribu. Ongeza tarehe, kwa sababu kurejesha snapshot au kusasisha hypervisor kunaweza kubadilisha vyote vinne.

Ikiwa IPv4 ilifuata tunnel, sema hivyo. Usipanue dai hilo kwa IPv6, nafasi nyingine ya majina au VM nyingine kwenye mtandao tofauti.