Archive for Outras

Raspberry Monitor de 7 polegadas, arrumando a resolução

Peguei o sdcard e coloquei no meu notebook.
Fui no diretório e procurei pelo arquivo config.txt
Adicionei os seguintes itens:


max_usb_current=1
hmdi_group=2
hdmi_mode=1
hdmi_mode87
hdmi_cvt 800 480 60 6 0 0 0 

Hairpin nat mikrotik – Acesso na intranet não funciona com direcionamento de portas

by https://wiki.mikrotik.com/wiki/Hairpin_NAT

Hairpin NAT
In the below network topology a web server behind a router is on private IP address space, and the router performs NAT to forward traffic to its public IP address to the web server behind it.

The NAT configuration would look like below:

/ip firewall nat
add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=80 \
action=dst-nat to-address=192.168.1.2
add chain=srcnat out-interface=WAN action=masquerade
When a client out on the Internet with IP address 2.2.2.2 establishes a connection to the web server, the router performs NAT as configured.

the client sends a packet with a source IP address of 2.2.2.2 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 2.2.2.2.
the server replies to the client’s request and the reply packet has a source IP address of 192.168.1.2 and a destination IP address of 2.2.2.2.
the router determines that the packet is part of a previous connection and undoes the destination NAT, and puts the original destination IP address into the source IP address field. The destination IP address is 2.2.2.2, and the source IP address is 1.1.1.1.
The client receives the reply packet it expects, and the connection is established.

When a client on the same internal network as the web server requests a connection to the web server’s public IP address, the connection breaks.

the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 192.168.1.10.
the server replies to the client’s request. However, the source IP address of the request is on the same subnet as the web server. The web server does not send the reply back to the router, but sends it back directly to 192.168.1.10 with a source IP address in the reply of 192.168.1.2.
The client receives the reply packet, but it discards it because it expects a packet back from 1.1.1.1, and not from 192.168.1.2. As far as the client is concerned the packet is invalid and not related to any connection the client previously attempted to establish.

To fix the issue, an additional NAT rule needs to be introduced on the router to enforce that all reply traffic flows through the router, despite the client and server being on the same subnet. The rule below is very specific to only apply to the traffic that the issue could occur with – if there are many servers the issue occurs with, the rule could be made broader to save having one such exception per forwarded service.

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 \
dst-address=192.168.1.2 protocol=tcp dst-port=80 \
out-interface=LAN action=masquerade
Hairpin nat 4.png

With that additional rule, the flow now changes:

the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. It also source NATs the packet and replaces the source IP address in the packet with the IP address on its LAN interface. The destination IP address is 192.168.1.2, and the source IP address is 192.168.1.1.
the web server replies to the request and sends the reply with a source IP address of 192.168.1.2 back to the router’s LAN interface IP address of 192.168.1.1.
the router determines that the packet is part of a previous connection and undoes both the source and destination NAT, and puts the original destination IP address of 1.1.1.1 into the source IP address field, and the original source IP address of 192.168.1.10 into the destination IP address field.
The client receives the reply packet it expects, and the connection is established.

However, the web server only ever sees a source IP address of 192.168.1.1 for all requests from internal clients regardless of the internal client’s real IP address. There is no way to avoid this without either using a router that can do application level DNS inspection and can rewrite A records accordingly, or a split DNS server that serves the internal clients the internal server IP address and external clients the external server IP address.

This is called – among other terms – hair pin NAT because the traffic flow has clients enter the router through the same interface it leaves through, which when drawn looks like a hair pin.

Tabela de conversão RSSI para dbm

Nota: Tabela para CISCO

Cisco has the most granular dBm lookup table.
RSSI_Max = 100
Convert % to RSSI and lookup the result in the following table. The RSSI is on the left,
and the corresponding dBm value (a negative number) is on the right.

0 = -113
1 = -112
2 = -111
3 = -110
4 = -109
5 = -108
6 = -107
7 = -106
8 = -105
9 = -104
10 = -103
11 = -102
12 = -101
13 = -99
14 = -98
15 = -97
16 = -96
17 = -95
18 = -94
19 = -93
20 = -92
21 = -91
22 = -90
23 = -89
24 = -88
25 = -87
26 = -86
27 = -85
28 = -84
29 = -83
30 = -82
31 = -81
32 = -80
33 = -79
34 = -78
35 = -77
36 = -75
37 = -74
38 = -73
39 = -72
40 = -70
41 = -69
42 = -68
43 = -67
44 = -65
45 = -64
46 = -63
47 = -62
48 = -60
49 = -59
50 = -58
51 = -56
52 = -55
53 = -53
54 = -52
55 = -50
56 = -50
57 = -49
58 = -48
59 = -48
60 = -47
61 = -46
62 = -45
63 = -44
64 = -44
65 = -43
66 = -42
67 = -42
68 = -41
69 = -40
70 = -39
71 = -38
72 = -37
73 = -35
74 = -34
75 = -33
76 = -32
77 = -30
78 = -29
79 = -28
80 = -27
81 = -25
82 = -24
83 = -23
84 = -22
85 = -20
86 = -19
87 = -18
88 = -17
89 = -16
90 = -15
91 = -14
92 = -13
93 = -12
94 = -10
95 = -10
96 = -10
97 = -10
98 = -10
99 = -10
100 = -10

Juniper SRX Port Forwarding / Destination NAT

Imagem 21

Resumo: Redirecionamento de portas usando CLI no Juniper SRX 240

SO: JUNOS Software Release [10.0R3.10]

juniper

1 – Configurar as entradas dos endereços das entidades:

set security zones security-zone DMZ-trust address-book address WebServer 10.254.254.2/32
set security zones security-zone DMZ-trust address-book address SftpServer 10.254.254.3/32

2 – Tradução das configurações de portas (nome para número):

set applications application HTTP protocol tcp
set applications application HTTP destination-port 80
set applications application SSH protocol tcp
set applications application SSH destination-port 22

3 – CONFIGURAÇÕES DE NAT

Ambos servidores e portas definidos com seus ips privados:

set security nat destination pool dnat_10_254_254_2m32 address 10.254.254.2/32 port 80
set security nat destination pool dnat_10_254_254_3m32 address 10.254.254.3/32 port 22

4 – Politica de Nat que faz a tradução:

set security nat destination rule-set DEST-NAT from zone untrust

Para o Web Server:

set security nat destination rule-set DEST-NAT rule WEB-SERVER-TCP-80 match destination-address 172.16.254.1/32
set security nat destination rule-set DEST-NAT rule WEB-SERVER-TCP-80 match destination-port 80
set security nat destination rule-set DEST-NAT rule WEB-SERVER-TCP-80 then destination-nat pool dnat_10_254_254_2m32

Para o SFTP

set security nat destination rule-set DEST-NAT rule SFTP-SERVER-TCP-22 match destination-address 172.16.254.1/32
set security nat destination rule-set DEST-NAT rule SFTP-SERVER-TCP-22 match destination-port 22
set security nat destination rule-set DEST-NAT rule SFTP-SERVER-TCP-22 then destination-nat pool dnat_10_254_254_3m32

5 – Configuração de Política de Segurança, IPs privados e portas de servidor Web e SFTP Server são definidos aqui:

para o Web Server:

set security policies from-zone untrust to-zone DMZ-trust policy INTERNET-TO-DMZ match source-address any
set security policies from-zone untrust to-zone DMZ-trust policy INTERNET-TO-DMZ match destination-address WebServer
set security policies from-zone untrust to-zone DMZ-trust policy INTERNET-TO-DMZ match application HTTP
set security policies from-zone untrust to-zone DMZ-trust policy INTERNET-TO-DMZ then permit

para o SFTP Server

set security policies from-zone untrust to-zone DMZ-trust policy INTERNET-TO-DMZ match source-address any
set security policies from-zone untrust to-zone DMZ-trust policy INTERNET-TO-DMZ match destination-address SftpServer
set security policies from-zone untrust to-zone DMZ-trust policy INTERNET-TO-DMZ match application SSH
set security policies from-zone untrust to-zone DMZ-trust policy INTERNET-TO-DMZ then permit

Substituição Ports Freebsd por SVN

As of July 2012, FreeBSD uses Subversion as the primary version control system for storing all of FreeBSD’s source code, documentation, and the Ports Collection.

Installation

# cd /usr/ports/devel/subversion
# make install clean

If the ports tree is not available, Subversion can be installed as a package:

# pkg install devel/subversion

Running Subversion

svn checkout https://svn.FreeBSD.org/ports/head /usr/ports

where:

svn-mirror is a URL for one of the Subversion mirror sites.

repository is one of the Project repositories, i.e., base, ports, or doc.

branch depends on the repository used. ports and doc are mostly updated in the head branch, while base maintains the latest version of -CURRENT under head and the respective latest versions of the -STABLE branches under stable/8 (for 8.x), stable/9 (9.x) and stable/10 (10.x).

lwcdir is the target directory where the contents of the specified branch should be placed. This is usually /usr/ports for ports, /usr/src for base, and /usr/doc for doc.

Because the initial checkout has to download the full branch of the remote repository, it can take a while. Please be patient.

After the initial checkout, the local working copy can be updated by running:

# svn update lwcdir

To update /usr/ports created in the example above, use:

# svn update /usr/ports

The update is much quicker than a checkout, only transferring files that have changed.

An alternate way of updating the local working copy after checkout is provided by the Makefile in the /usr/ports, /usr/src, and /usr/doc directories. Set SVN_UPDATE and use the update target. For example, to update /usr/src:

# cd /usr/src

# make update SVN_UPDATE=yes

Ref: https://www.freebsd.org/doc/handbook/svn.html