oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: nat

Windows 10: Internal Virtual Switch with NAT

2021/07/12 1 comentari
Reading time: 2 – 4 minutes

When you are playing with Windows Hyper-V and you want to create a completely virtual internal network with private virtual machines inside your Windows 10 machine virtual switch are mandatory.

Then it’s the time to connect that virtual switch with the host machine using a virtual network interface. All those steps can be done using Hyper-V manager user interface, but you cannot control 100% of parameters like enable, or not, the NAT of the virtual internal network.

Using PowerShell the steps are:

New-VMSwitch -SwitchName NATSwitch -SwitchType Internal
New-NetIPAddress -IPAddress 10.46.1.1 -PrefixLength 24 -InterfaceAlias "vEthernet (NATSwitch)"
New-NetNAT -Name NATNetwork -InternalIPInterfaceAddressPrefix 10.46.1.0/24

Of course, change “NATSwitch” for your switch name and “10.46.1.1” for the IP address of the host virtual network card. Finally “NATNetwork” is another arbitrary name for referring to the NAT rule, and “10.46.1.0/24” is the network address of the virtual internal host network.

Running the commands looks like:

For removing what you did:

Remove-VMSwitch -Name "NATSwitch"
Remove-NetIPAddress -InterfaceAlias "vEthernet (NATSwitch)"
Remove-NetNAT -Name NATNetwork

In Windows 10 IP forwarding is not enabled and packets between interfaces are not routed. According to the Microsoft forums, you can enable IP forwarding (routing) using the following steps:

Go to Start and search on cmd or command. Right click on either cmd or command then select Run as administrator. At the command prompt type regedit. Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Tcpip\Parameters\IPEnableRouter setting, right click and select Modify. Change 0 to 1 and exit the editor.

When your back at the command prompt type services.msc and navigate to the Routing and Remote Access service. Right click and select Properties. Change to Automatic and click on Start to start the service.

I had to research a long time until I found all this information, but in my case leverage my proofs of concepts to another level.

NAT traversal: Com funciona ICE?

2009/06/10 No hi ha comentaris

Reading time: 5 – 8 minutes

Per tal d’entendre com funciona ICE el millor és explicar-lo conjuntament amb un altre protocol; ja que com es va comentar a la introducció del NAT traversal el protol ICE usa una combinació del protocol TURN i STUN en funció del cas, això és molt senzill d’entendre si parlem d’un cas pràctic d’ús. O sigui, quan s’intenta que per exmple, SIP travessi un firewall/gateway/router per fer arribar una trucada a un telefon IP.

Què són els candidats?

El Caller envia un missatge de SIP INVITE amb informació SDP que descriu per quina IP i per quins PORTS l’aplicació pot rebre audio i/o video. Aquestes adreces i ports es coneixen com candidates. Aquests candidates s’obtenen del servidor ICE (sovint es troba dins el firewall/router/gateway).

Podriem descriure un candidate com una IP i un port a través dels quals un peer pot rebre dades d’un altre peer. Hi ha tres tipus de candidates:

  • Local candidate: IP local del client.
  • Reflexive or STUN candidates: una adreça IP pública del servidor NAT.
  • Relay o TURN candidate: una adreça o un relay server que ha estat reservat pel client.

El tràfic sempre es podrà enviar amb èxit a través dels relay candidates, a menys que un firewall bloquegi l’enllaç, aleshores no hi ha tècnica possible de NAT traversal a aplicar. El problema d’usar relay candidates és que requereix usar recursos d’un servidor, això fa que el tràfic que arriba al peer tingui retards, perdues i problemes de jitter.

Procés d’establiment d’una trucada SIP via ICE

1. Caller aconsegueix els seus candidates

En el següent gràfic es pot veure com el Caller determinada els reflexive i relay candidates per una connexió. El client envia una petició d’ALLOCATE al servidor, llavors el servidor localitza un parell IP/port (el relay candidate). Aquesta informació s’envia altre cop al Caller (reflexive candidate), aquest missatge conté la IP pública que usarà el Caller quan emeti un missatge a internet, sovint això és la IP a través de la qual s’aplicarà el NAT.

stun_turn_candidates

2. Caller envia un SIP INVINTE

El Caller construeix un missatge SIP INVITE usant la informació dels candidates que ha obtingut del seu servidor ICE, després l’envia al seu destí.

3. Callee aconsegueix els candidates

Quan es rep el missatge SIP INVITE, el Callee aconsegueix els candidates de la mateixa manera que ho ha fet el Caller en el punt (1).

4. El Callee envia una resposta 1xx

Seguint amb el protocol SIP, el Callee ha de generar un missatge de resposta al SIP INVITE, per exemple, un SIP 183 (Session Progress). Quan es construeixi aquest missatge dins de l’informació SDP el Callee també hi encapsularà els seus candidates. Fins que aquest missatge no s’hagi rebut i confirmat per part del Caller (200 OK) no es considerarà exitosa la negociació.

5. ICE connectivity checks

Arribats en aquest punt tan el Caller com el Calle saben mutuament els candidates que tenen cadascún i és el moment d’usar el que s’anomena ICE connectivity checks. Això es fa enviant un missatge STUN des del local candidate cap al remote candidate, això es pot fer per tants candidates com hi hagin des del que té més prioritat fins al que en té menys. Això ho faran ambdós costats de l’enllaç si és que tots dos es troven darrera un gateway amb ICE. Quan s’hagi determinat quin dels candidates és el millor per establir cada un dels canals llavors s’escollirà aquest candidate per començar a enviar i rebre media a través seu.

A continuació es poden veure tres exemples de com es fan aquestes proves dels candidates. El primer esquema seria el cas en que ambdós hosts són enrutables directament perquè, per exmple, estan a la mateixa LAN. El segon esquema s’aconseguiria l’enllaç via la metologia STUN i en el tercer via la metodologia TURN.

ICE_connection_check

6. Callee envia SIP 180 (ringing)

En aquest punt el Callee envia el missatge SIP 180 (ringing) al Caller per informar-lo de que el teléfon del Callee esta sonant. Al haver negociat previament el canal de dades a través d’ICE quan el Callee despengi el teléfon ja podrà parlar sense retards, si això es negocies després hi hauria un efecte de retard desagradable pels peers.

7. Accepta la trucada i parlen

Així doncs, quan el Callee despengi s’enviarà un missatge 200 OK i via RTP (per exemple) i usant els canals negociats via ICE el fluxe de dades multimedia (en aquest cas audio) començarà travessant de forma transparent els dos gateways que donen accés a internet als dos peers.

Unes notes per aclarir el tema

En aquest exemple es preten demostrar que podem establir un enllaç RTP a través de dos peers que es troben darrera de NAT gràcies al protocol ICE. Com a protocol per controlar la sessió RTP s’usa SIP, això fa que ambdós peers necessitin una redirecció DNAT al seu gateway cap als ports TCP/UPD 5060. En cas de voler evitar això el que s’hauria d’usar és un altre protocol de senyalització diferent de SIP. Per exemple, si no volem/podem redirigir cap port al gateway es podria usar XMPP.

Glosari

  • Caller: qui fa la trucada
  • Calee: qui rep la trucada
  • SDP: Session Description Protocol
  • SIP: Session Initiation Protocol
  • Peer: un extrem de la connexió

Referències


NAT traversal: Com funciona STUN?

2009/05/28 3 comentaris

Reading time: 2 – 3 minutes

El servidor STUN ha de publicar la seva IP (3478TCP/UPD o 5349TLS) a un gateway que tingui una IP interna i una externa (privada i pública). La comuniació comença quan el client que esta a la xarxa enmascarada llença una serie de requests contra la IP pública del servidor STUN. El servidor STUN contestarà al client informant dels parells de ports usats a l’exterior del NAT, amb això el client aprent de quin tipus de NAT disposa i quin és el TTL dels bindings que es fan a l’exterior per re-enviar les seves peticions.

Una aplicació client per tal de saber qui és el seu servidor STUN el que fa és buscar al seu domini DNS la resolució del nom _stun_.domini_exemple.com o _stun._udp.domini_exemple.com pels tipus de registre SRV. Després de saber qui és el seu servidor STUN el que fa l’aplicació és buscar l’adreça pública del servidor STUN. Per tal de descobrir quin haurà de ser l’origen dels seus paquets a internet. Així quan construeixi els paquets amb les dades d’aplicació podrà advertir quina és l’adreça pública del seu servidor STUN.

Arribats a aquest punt sovint en tenim prou com per començar la comunicació amb el destí final del nostre enllaç, ja que aquest l’únic que haurà de fer és contestar els paquets pels mateixos ports que el gateway esta fent binding en aquell moment. Aquí és on el STUN server fa la seva feina mantenint els ports oberts. Un dels problemes amb els que ens podem trobar és que el node destí no pugui atacar aquells ports per alguna restricció del seu firewall o similar. Cosa que complica la possibilitat de fer l’enllaç. Si els dos hosts que volem comunicar estan tots dos darrera del NAT-masquerade la cosa és fa molt difícil i sovint fa falta un proxy entre els dos servidors STUN per tal de que la cosa funcioni, o sigui, que es complica moltíssim.

Diagrama de fluxe del protocol:

Esquema NAT
Click for (+) Zoom

NAT traversal: Introducció

2009/05/27 1 comentari

Reading time: 3 – 5 minutes

Avui en dia és molt usual tenir xarxes darrera de gateways (routers, firewalls, etc) que a través de NAT donen accés a internet als hosts, sovint anomenem masquerading a aquesta funcionalitat que no deixa de ser un subconjunt de funcions del propi NAT. La majoria de problemes associats a l’accés a internet via masquerading estan solucionats. Però quan el problema que tenim és l’invers, o sigui, que volem accedir, via TCP o UDP, a un host  que esta dintre una xarxa amb un gateway que fa NAT la cosa es complica.

De fet, si el que volem és redirigir un port de la IP pública amb la que s’accedeix a internet a un host intern tampoc no té massa misteri, gràcies al DNAT. Però si aquestes redireccions han de ser a més d’un host sovint hem de començar a usar ports no massa estàndards per oferir serveis que hi ha dins la xarxa i que volem publicar a internet. O sigui, que l’únic que podem fer a priori és mapejar estàticament ports de la IP pública cap a certs ports de les IPs privades.

Per tal de poder rebre connexions en un host que esta darrera un gateway que fa NAT hi ha una serie de tècniques més o menys (des)conegudes.

  • TURN (Traversal Using Relay NAT): la idea és tenir un pool d’IPs públiques de forma que les aplicacions que necessitin ser publicades a internet agafin una IP disponible de forma temporal o permanen per publicar aquell servei en aquella IP que mapejarà els seus ports. O sigui, que es basa en una idea similar al DNAT però li afegeix la capacitat de poder usar pools d’IPs de forma dinàmica.
  • STUN (Session Traversal Utilities for NAT): Esta orientat a aplicacions de VoIP, missatgeria, videoconferència, etc. Sovint quan les connexions per les que s’usa STUN són via UDP, malgrat també hi poden haver servidors que STUN que funcionin amb TCP o fins hi tot TCP/TLS.  El protol STUN és un protocol client-servidor molt lleuger.
  • ICE (Interactive Connectivity Establishment): finalment la idea d’ICE és buscar la millor ruta entre dos hosts que volen comunicar-se. Si ambdós estan dintre la mateixa LAN o en LANs diferents però tenen IPs públiques o NATs estàtics (1a1), llavors enruta les connexions i llestos. Però si els hosts estan darrera de NAT que fan enmascarament dinàmic llavors usa combinacions de les tènciques d’STUN i TURN.

Per tal d’entendre millor aquests problemes cal tenir clar els tipus de NAT que existeixen:

  • Full Cone NAT

    • Esquema NAT
    Click for (+) Zoom

  • Port Restricted Cone NAT

    • Esquema NAT
    Click for (+) Zoom

  • Restricted Cone NAT

    • Esquema NAT
    Click for (+) Zoom

  • Symetric NAT

    • Esquema NAT
    Click for (+) Zoom

    En els propers articles desenvoluparé més a fons els protocols citats i referenciaré algunes llibreries que els implementen.

    La major part de la bibliografia l’he extret de la wikipedia, dels estàndards IETF i de les següents fonts:

    • PDF de NAT types de la web: http://www.crfreenet.org/~martin/referaty/stun/naty.pdf (local)

Servidor FTP darrera un NAT (pure-ftpd)

2007/07/05 No hi ha comentaris

Reading time: 2 – 2 minutes

Sovint quan montem un servidor FTP darrera d’un Firewall que fa DNAT per publicar els ports FTP (20, 21, tcp i udp) a internet ens deixa de funcionar l’FTP en mode Passive On. Llavors hem de fer allò tan molest i depenent del client tan difícil; o sigui, fer un Passive Off perquè la transmissió d’arxius, llistats de fitxers, etc. funcioni bé. Doncs avui cansat d’això en un servidor pure-ftpd que tinc montat a la feina i he posat solució ja que sinó tenia als tècnics molt limitats quan es trobaven a casa dels clients.

La cosa ha estat ben senzilla, només he hagut de llençar el pure-ftpd amb el paràmetre -p i especificar un rang de ports per on es faran les connexions passives. Jo he decidit que anessin entre el port 40000 i el 50000. Així doncs, el paràmetre ha quedat així: -p 40000:50000. Després al firewall he redirigit tot aquest rang de ports contra la IP interna del servidor i llestos (fent un DNAT). Ara ja funcionen perfectament els FTP passius.

Si tot això d’FTP passiu i no passiu, ús sona a xinès he trobat una petita web molt bona que explica la diferència entre un sistema i l’altre: Active FTP vs. Passive FTP, a Definitive Explanation (local).

nat traversal

2005/10/23 No hi ha comentaris

Reading time: 2 – 4 minutes

A vegades tampoc em funcionen les coses a mi, a què ve aquest comentari? doncs resulta que hi ha més d’un amic que em diu que li dona la sensació que sempre me’n surto de tot doncs bé. Aquí us parlo d’una eina que no he aconseguit que em funcionés tinc diverses teories del perquè però la veritat és que com que de moment no la necessito m’he cansat de seguir provant, o sigui, que de moment he de dir que no me n’he sortit a usar-la.

L’eina té molt bona pinta es diu nat-traversal serveix per connectar a ports de màquines internes que estan darrera de sistemes enmascarats (darrera de NAT). La web és molt explicativa i útil.

nat-traverse establishes connections between nodes which are behind NAT gateways, i.e. hosts which do not have public IP addresses. Additionally, you can setup a small VPN by using pppd on top of nat-traverse. nat-traverse does not need an external server on the Internet, and it isn’t necessary to reconfigure the involved NAT gateways, either. nat-traverse works out-of-the-box.

Tot i amb això trobo súper interessant la tècnica que usent fer entrar a través del NAT fins al PC que teoricament no té els ports públics:

1.Firstly, nat-traverse on host left sends garbage UDP packets to the NAT gateway of right. These packets are, of course, discarded by the firewall.

2.Then right’s nat-traverse sends garbage UDP packets to the NAT gateway of left. These packets are not discarded, as left’s NAT gateway thinks these packets are replies to the packets sent in step 1!

3.left’s nat-traverse continues to send garbage packets to right’s NAT gateway. These packets are now not dropped either, as the NAT gateway thinks the packets are replies to the packets sent in step 2.

4.Finally, both hosts send an acknowledgement packet to signal readiness. When these packets are received, the connection is established and nat-traverse can either relay STDIN to the socket or execute a program.

Jo concretament el que he provat és de redirigir un port amb el netcat, però el problema que crec que tinc és que jo no faig un ‘masquerade’ al firewall que tinc davant, sinó un ‘SNAT’ i per si fos poc abans d’arribar al firewall passo per un router intern, així doncs segur que hi ha alguna cosa pel camí que m’està estorbant, però com comentava abans com que de moment no necessito l’eina ja m’he cansat d’insisitir. Aquí queda el tema fins que realment em fassi falta o algú s’hi posi i em digui què tal.

Truquillo: desactivar regla de NAT a una CLI Cisco

2005/09/10 No hi ha comentaris

Reading time: 1 – 2 minutes

cisco.gif

Hi ha una comanda dels routers Cisco que sempr se m’oblida de fet és una tonteria però cansat de perdre sempre 5min buscant-la quan la necessito m’he decidit a escriure aquest post al blog.

Quan tenim regles de DNAT, SNAT o simplement NAT a un router Cisco si aquesta regla està en ús no podem desactivar-la amb la típica instrucció:

no ip nat {inside | outside}

Ja que dona el següent error: Dynamic mapping in use, cannot remove així que el que primer hem de fer és el següent:

clear ip nat translation force

Per més informació sobre el tema el document oficial de Cisco que parla del tema és: How to Change the Dynamic NAT Configuration (pdf).