Disparador de ports enfront del reenviament de ports per a un servidor VPN domèstic
El disparador obre una assignació després del trànsit de sortida; el reenviament assigna el port de manera permanent. Un servidor VPN domèstic necessita el segon, limitat a l’oient real.
El reenviament de ports i el disparador de ports són al mateix menú a la majoria d’encaminadors domèstics, i per això es tracten com dues maneres de fer una sola feina. El reenviament és una regla estàtica: una connexió entrant a un port WAN es tradueix a una adreça i un port interns fixos, passi o no passi res més. El disparador és condicional: l’encaminador vigila el trànsit de sortida i només obre una assignació entrant després que surti una connexió coincident. Un servidor VPN espera que algú altre es connecti primer, així que aquesta condició és l’única cosa que no pot complir mai.
Dues regles amb cicles de vida diferents
L’NAT d’IPv4 té estat. Quan un equip intern envia un paquet cap a fora, l’encaminador crea una assignació perquè les respostes trobin el camí de tornada; un paquet entrant que no coincideix amb cap assignació es descarta, i aquest és el comportament que manté un escriptori sense actualitzar fora d’internet. El reenviament és una entrada de traducció permanent afegida a mà. El disparador és un forat temporal protegit per un patró de trànsit.
La diferència pràctica és el temps. Un reenviament existeix des del moment en què es desa fins que algú l’esborra. Una assignació disparada existeix després que el disparador s’activi i es tanca amb un temporitzador d’inactivitat, mesurat en minuts en maquinari de consum, o immediatament en reiniciar.
Cap dels dos no és més segur en abstracte. Un reenviament exposa un port de manera continuada; un disparador l’exposa només després d’un trànsit de sortida concret. Per a un servei que ha d’acceptar el primer paquet d’un desconegut, només un dels dos encaixa amb la feina.
Per què el disparador no publicarà un servidor
Un servidor VPN és passiu per disseny. El parell, sigui un portàtil en un cafè o un mòbil amb dades mòbils, envia el primer paquet, i l’encaminador no té cap assignació per a ell. Res de dins no ha iniciat trànsit cap al port del disparador, així que la regla no s’activa mai i la connexió mor abans que comenci la negociació.
On el disparador sembla funcionar, alguna altra cosa genera trànsit al port del disparador: un client a la LAN, una sonda de monitoratge o les comprovacions de sortida del mateix servidor. Llavors l’assignació s’obre per a aquell únic equip i es tanca quan el trànsit s’atura, així que el següent parell extern torna a fallar mentre el primer èxit queda al registre com si fos una prova.
El disparador també sol ser d’un sol equip. Moltes implementacions permeten que només un dispositiu intern tingui l’assignació alhora, cosa del tot equivocada per a un servidor que ha de respondre a diversos parells. La funció es va crear per a aplicacions que obren una connexió de control cap a fora i esperen dades entrants en un segon port, i encara encaixa en aquesta forma.
Què assigna realment un reenviament
Un reenviament és una entrada de traducció: port WAN i protocol cap a adreça i port interns. Necessita un oient que ja s’executi a l’altre costat, i necessita que l’adreça interna es quedi on és. Una concessió DHCP que es trasllada a una altra màquina envia cada túnel a l’equip equivocat, en silenci, així que creeu la reserva abans de la regla.
| Rule | Opens when | Closes when | Fits a VPN listener |
|---|---|---|---|
| Port forward | Saved, at boot | You delete it | Yes |
| Port trigger | Matching outbound traffic | Idle timeout or reboot | No |
El protocol importa més del que suggereix el formulari. OpenVPN sobre UDP necessita un reenviament UDP, WireGuard necessita UDP, i les dades d’IPsec arriben com a ESP, protocol IP 50, que no té cap port. Un formulari de reenviament que només accepta TCP o UDP no ho pot expressar, així que IPsec necessita passthrough o una assignació estàtica un a un en lloc d’una regla de port.
La capa per damunt de l’encaminador
Un reenviament només controla la traducció que és vostra. Si l’adreça WAN no és vostra, que és el cas darrere d’una NAT d’operador on els abonats comparteixen 100.64.0.0/10 tal com es descriu a RFC 6598, la connexió entrant no arriba mai al vostre encaminador perquè el proveïdor ha traduït primer. Cap regla del vostre dispositiu no pot arreglar aquest ordre.
El doble NAT és el mateix problema en miniatura. El vostre encaminador reenvia cap a l’encaminador de l’ISP, que no té cap regla coincident i descarta el paquet. O afegiu la regla al dispositiu exterior, o poseu el dispositiu exterior en mode pont i deixeu que el vostre tingui l’adreça pública.
Per això la prova ha de venir de fora. Una prova des de la mateixa LAN a través de l’adreça pública depèn del suport d’hairpin NAT i pot passar o fallar per motius aliens a la regla; un mòbil amb dades mòbils, o un amic en una altra xarxa, és la comprovació més neta.
Limiteu la regla i verifiqueu les dues meitats
Reenvieu un port a una adreça. Un rang afegit perquè els primers intents van fallar és com les interfícies de gestió acaben a internet, i l’oient del VPN no necessita la pàgina d’administració de l’encaminador publicada al costat.
Conserveu tot el que ja protegia aquell oient: identitat per certificat o clau, tallafocs de l’equip, versions actuals dels paquets. Un reenviament deixa entrar un paquet; l’autenticació decideix si el paquet es converteix en túnel, i són dues fallades separades quan alguna cosa va malament.
La verificació té dues meitats. La negociació s’ha de completar des d’una xarxa externa, i després un recurs privat darrere del servidor ha de respondre pel túnel. El reenviament admet la connexió del túnel i res més; l’encaminament i l’autorització per a 10.8.0.0/24 són un altre paràmetre en una altra pantalla.
Decidiu amb tres preguntes
Tres preguntes resolen l’elecció més de pressa que qualsevol taula comparativa:
- Hi ha alguna cosa que es connecti des de fora, com a primer paquet? Doncs feu servir el reenviament, o un relé. El disparador no es pot obrir sense un trànsit de sortida que no existirà mai.
- El forat ha de sobreviure al temps d’inactivitat? Doncs feu servir el reenviament, perquè una assignació disparada es tanca segons el seu propi calendari.
- L’adreça WAN és vostra per publicar-la? Si no ho és, arregleu la capa de dalt abans d’editar cap regla.
Si la resposta a les tres preguntes és no, que és el cas d’un portàtil que marca un proveïdor comercial, no cal cap de les dues regles. Un client darrere de NAT funciona perquè crea ell mateix l’assignació amb estat, i això cobreix la majoria de les persones que llegeixen una pàgina de reenviament de ports a mitjanit.