Elasticsearch:使用 GeoIP 丰富来自内部专用 IP 地址
转载自:https://blog.csdn.net/UbuntuTouch/article/details/108614271
对于公共 IP,可以创建表来指定 IP 属于哪个城市的特定范围。但是,互联网的很大一部分是不同的。在世界上每个国家都有公司专用网络,其 IP 地址的格式为 10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16。这些 IP 地址往往没有有关地理位置的真实信息。因此,Elasticsearch 和 Logstash 中内置的 geoip 过滤器/处理器不适用于这些私有 IP。
Elasticsearch 和 Logstash 可以选择指定要使用的特定数据库文件(database / database_file),因此从理论上讲,可以自定义构建。但是,这可能会很耗时,而且维护成本很高,更不用说你可能必须学习一套新工具来仅构建这些 .mmdb 文件(这个在以后的话题中讲)。
可以使用 Elasticsearch 中已经内置的另一个工具(enrich processor)来实现一种更简单的方法,该工具可以(非常令人惊讶地)用我们想要的任何种类的数据(包括地理数据)丰富我们的文档。让我们来看一个这样做的例子。
示例:通过大陆,国家/地区和城市来丰富私有 IP
在本例中,我将只讲到任意选择的国家/地区中的城市,但是很容易看出如何将其精确化到村庄或甚至是特定建筑物的水平,或者只精确到国家或地区。 这仅取决于特定用例需求。
我们首先来创建一个 private_geoips 的索引:
PUT private_geoips
{
"mappings": {
"properties": {
"city_name": {
"type": "keyword"
},
"continent_name": {
"type": "keyword"
},
"country_iso_code": {
"type": "keyword"
},
"country_name": {
"type": "keyword"
},
"location": {
"type": "geo_point"
},
"source.ip": {
"type": "ip"
}
}
}
}
要实现这样的功能,我们需要控制在办公室的哪些位置使用哪些私有 IP。 考虑到专用网络的性质,总是有发生重叠的机会。 对于这个小例子,我们将想象我们可以控制不同办公室的某些子网,而我将其分配如下:
10.4.0.0/16 - Pretoria South Africa (比勒陀利亚南非)
10.5.0.0/16 - Toronto Canada(加拿大多伦多)
10.6.0.0/16 - Berlin Germany(柏林德国)
10.7.0.0/16 - Tokyo Japan(日本东京)
我们接下来导入如下的数据到索引 private_geoips 中:
POST private_geoips/_bulk
{"index":{"_id":"pretoria-south-africa"}}
{"city_name":"Pretoria","continent_name":"Africa","country_iso_code":"SA","country_name":"South Africa","location":[28.21837,-25.73134],"source.ip":["10.4.54.6","10.4.54.7","10.4.54.8"]}
{"index":{"_id":"toronto-canada"}}
{"city_name":"Toronto","continent_name":"North America","country_iso_code":"CA","country_name":"Canada","location":[-79.347015,43.65107],"source.ip":["10.5.231.89","10.5.231.90","10.5.231.91"]}
{"index":{"_id":"berlin-germany"}}
{"city_name":"Berlin","continent_name":"Europe","country_iso_code":"DE","location":[13.404954,52.520008],"country_name":"Germany","region_name":"","source.ip":["10.6.132.43","10.6.132.44"]}
{"index":{"_id":"tokyo-japan"}}
{"city_name":"Tokyo","continent_name":"Asia","country_iso_code":"JP","country_name":"Japan","location":[139.839478,35.652832],"source.ip":["10.7.1.76"]}
我们存储在索引 private_geoips 中的所有文档都必须具有策略 (policy)内 enrich_fields 数组中提到的所有字段。
PUT _enrich/policy/private_geoips_policy
{
"match": {
"indices": "private_geoips",
"match_field": "source.ip",
"enrich_fields": [
"city_name",
"continent_name",
"country_iso_code",
"country_name",
"location"
]
}
}
对于 enrich processor 还是不太了解的开发者来说,你可以参阅我之前的文章 “Elasticsearch:如何使用 Elasticsearch ingest 节点来丰富日志和指标”。其基本意思是当一个文档的 source.ip 字段和 private_geoips 索引中的 source.ip 中的一个比对成功的话,那么在 private_geoips 中的其它字段 "city_name", "continent_name", "country_iso_code", "country_name", "location" 将会被丰富到文档中。
当我们第一次创建策略或更改索引时,我们需要重新执行策略。
POST /_enrich/policy/private_geoips_policy/_execute
让我们创建我们的 ingest pipeline:
PUT /_ingest/pipeline/private_geoips
{
"description": "_description",
"processors": [
{
"dot_expander": {
"field": "source.ip"
}
},
{
"enrich": {
"policy_name": "private_geoips_policy",
"field": "source.ip",
"target_field": "geo",
"max_matches": "1"
}
},
{
"script": {
"lang": "painless",
"source": "ctx.geo.remove('source.ip')"
}
}
]
}
最后,我们来测试 ingest pipeline:
POST /_ingest/pipeline/private_geoips/_simulate
{
"docs": [
{
"_source": {
"source.ip": "10.7.1.76"
}
},
{
"_source": {
"source.ip": "10.4.54.7"
}
}
]
}
运行上面的测试,我们可以看到如下的结果:
{
"docs" : [
{
"doc" : {
"_index" : "_index",
"_type" : "_doc",
"_id" : "_id",
"_source" : {
"geo" : {
"continent_name" : "Asia",
"country_name" : "Japan",
"city_name" : "Tokyo",
"location" : [
139.839478,
35.652832
],
"country_iso_code" : "JP"
},
"source" : {
"ip" : "10.7.1.76"
}
},
"_ingest" : {
"timestamp" : "2020-09-16T01:16:55.901889Z"
}
}
},
{
"doc" : {
"_index" : "_index",
"_type" : "_doc",
"_id" : "_id",
"_source" : {
"geo" : {
"continent_name" : "Africa",
"country_name" : "South Africa",
"city_name" : "Pretoria",
"location" : [
28.21837,
-25.73134
],
"country_iso_code" : "SA"
},
"source" : {
"ip" : "10.4.54.7"
}
},
"_ingest" : {
"timestamp" : "2020-09-16T01:16:55.901897Z"
}
}
}
]
}
就是这样! 现在,您的私有 IP 地址已充实了 private_geoips 索引中存储的地理位置数据。 现在,您需要做的就是维护该查找索引。
Elasticsearch:使用 GeoIP 丰富来自内部专用 IP 地址的更多相关文章
- IP地址规划和设计方法
IP地址规划和设计方法 无类域间路由技术需要在提高 IP 地址利用率和减少主干路由器负荷两个方面取得平衡 网络地址转换 NAT 最主要的应用是专用网,虚拟专用网,以及 ISP 为拨号用户 提供的服务 ...
- APIPA(Automatic Private IP Addressing,自动专用IP寻址)
APIPA APIPA(Automatic Private IP Addressing,自动专用IP寻址),是一个DHCP故障转移机制.当DHCP服务器出故障时, APIPA在169.254.0.1到 ...
- 计算机网络学习笔记--网络层之IP地址与子网
IPv4地址: 我们知道在网络层(TCP/IP体系结构的网际互联层),最重要的一个协议就是IP协议,现在正处于IPv4和IPv6的过渡时期,但目前来说,IPv4仍为主流,所以主要讲Ipv4. IP地址 ...
- ip地址分类和网段区分
IP地址分类/IP地址10开头和172开头和192开头的区别/判断是否同一网段 简单来说在公司或企业内部看到的就基本都是内网IP,ABC三类IP地址里的常见IP段. 每个IP地址都包含两部分,即网络号 ...
- IP地址和子网划分学习笔记之《IP地址详解》
2018-05-03 18:47:37 在学习IP地址和子网划分前,必须对进制计数有一定了解,尤其是二进制和十进制之间的相互转换,对于我们掌握IP地址和子网的划分非常有帮助,可参看如下目录详文. ...
- IP地址分类/IP地址10开头和172开头和192开头的区别/判断是否同一网段(A、B、C三类地址)【转】
简单来说在公司或企业内部看到的就基本都是内网IP,ABC三类IP地址里的常见IP段. 每个IP地址都包含两部分,即网络号和主机号. InterNIC将IP地址分为五类:A类保留给ZF或大型企业,B类分 ...
- IP地址分类和网段区分的知识
IP地址分类/IP地址10开头和172开头和192开头的区别/判断是否同一网段 简单来说在公司或企业内部看到的就基本都是内网IP,ABC三类IP地址里的常见IP段. 每个IP地址都包含两部分,即网络号 ...
- IP地址的规划和设计方法(三)
九,内部网络专用IP地址规划与网络地址转换NAT方法 (1)内部网络的专用IP地址选择的根据 RFC1918在讨论内部网络的专用IP地址规划方法时任务.使用专用地址规划一个内部网络地址系统时.首选的方 ...
- 快速获取 IP 地址
IP 地址可以分为两类,公用和私有(专用).公用 IP 是唯一的 IP 地址,可以从 Internet 访问.专用 IP 地址保留供您专用网络内部使用,而不会直接暴露给 Internet. 本文将介绍 ...
随机推荐
- PostgreSQL下的SQL Shell(psql)工具
首发微信公众号:SQL数据库运维 原文链接:https://mp.weixin.qq.com/s?__biz=MzI1NTQyNzg3MQ==&mid=2247485130&idx=1 ...
- 21条最佳实践,全面保障 GitHub 使用安全
GitHub 是开发人员工作流程中不可或缺的一部分.无论你去哪个企业或开发团队,GitHub 都以某种形式存在.它被超过8300万开发人员,400万个组织和托管超过2亿个存储库使用.GitHub 是世 ...
- 标准的Switch语句和穿透的Switch语句
第三章 选择语句 3.1选择语句--Switch switch语句格式: ```java switch(表达式){ case 常量值1: 语句体1; break; case 常量值2: 语句体2; b ...
- python 面向对象理解
简介 与java语言一样,python也属于面向对象编程,除此之外,还有面向过程编程.函数式编程. 面向过程编程:依据业务逻辑自上而下一步一步编写, 可能会存在冗余现象 函数式编程:需要编程语言可以将 ...
- Java中类成员访问权限修饰符(public、protected、default、private)
1.public(公共的): 任何类都可以进行访问(最不严格). 2.protected(保护的): 同一包内的类以及其子类可以进行访问. 3.default(缺省的): 类中不加任何访问权限限定的成 ...
- 从零开始Blazor Server(6)--基于策略的权限验证
写这个的原因 现在BootstrapBlazor处于大更新时期,Menu组件要改为泛型模式. 本来我们的这一篇应该是把Layout改了,但是改Layout肯定要涉及到菜单,如果现在写了呢,就进入一个发 ...
- v-model原理问题
v-model的原理 很多同学在理解Vue的时候都把Vue的数据响应原理理解为双向绑定,但实际上这是不准确的,我们之前提到的数据响应,都是通过数据的改变去驱动DOM重新的变化,而双向绑定已有数据驱动D ...
- Postman如何通过xmysql工具的Restful API 接口访问MySQL
GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源. 导语 有时候用 Postman 接口测试需要获取MySQL的查询结果做接口输出的校验,这里介绍下 Postman 通过 R ...
- Kotlin协程解析系列(上):协程调度与挂起
vivo 互联网客户端团队- Ruan Wen 本文是Kotlin协程解析系列文章的开篇,主要介绍Kotlin协程的创建.协程调度与协程挂起相关的内容 一.协程引入 Kotlin 中引入 Corout ...
- 三道MySQL联合索引面试题,淘汰80%的面试者,你能答对几道
众所周知MySQL联合索引遵循最左前缀匹配原则,在少数情况下也会不遵循(有兴趣,可以翻一下上篇文章). 创建联合索引的时候,建议优先把区分度高的字段放在第一列. 至于怎么统计区分度,可以按照下面这种方 ...