Declanșarea porturilor versus redirecționarea porturilor pentru un server VPN de acasă
Declanșarea deschide o mapare după traficul de ieșire; redirecționarea mapează portul definitiv. Un server VPN de acasă are nevoie de a doua, limitată la ascultătorul real.
Redirecționarea porturilor și declanșarea porturilor stau în același meniu pe majoritatea routerelor de acasă, de aceea sunt tratate ca două moduri de a face o singură treabă. Redirecționarea este o regulă statică: o conexiune de intrare către un port WAN este tradusă într-o adresă și un port interne fixe, indiferent dacă se întâmplă altceva. Declanșarea este condiționată: routerul urmărește traficul de ieșire și deschide o mapare de intrare abia după ce iese o conexiune potrivită. Un server VPN așteaptă ca altcineva să se conecteze primul, așa că exact acea condiție este singurul lucru pe care nu îl poate îndeplini niciodată.
Două reguli cu cicluri de viață diferite
NAT-ul IPv4 este cu stare. Când un host intern trimite un pachet spre exterior, routerul creează o mapare astfel încât răspunsurile să găsească drumul înapoi; un pachet de intrare care nu corespunde niciunei mapări este aruncat, iar acest comportament ține un desktop neactualizat în afara internetului. Redirecționarea este o intrare de traducere permanentă adăugată manual. Declanșarea este o gaură temporară păzită de un model de trafic.
Diferența practică este timpul. O redirecționare există din momentul salvării până când cineva o șterge. O mapare declanșată există după ce declanșatorul se activează și se închide pe un temporizator de inactivitate, măsurat în minute pe hardware de consum, sau imediat la repornire.
Niciuna nu este mai sigură în abstract. Redirecționarea expune un port în permanență; declanșatorul îl expune doar după un anumit trafic de ieșire. Pentru un serviciu care trebuie să accepte primul pachet de la un necunoscut, doar una dintre cele două se potrivește sarcinii.
De ce declanșarea nu va publica un server
Un server VPN este pasiv prin construcție. Partenerul, fie că este un laptop într-o cafenea sau un telefon pe date mobile, trimite primul pachet, iar routerul nu are nicio mapare pentru el. Nimic din interior nu a început trafic către portul de declanșare, așa că regula nu se activează niciodată și conexiunea moare înainte de a începe handshake-ul.
Acolo unde declanșarea pare să funcționeze, altceva generează trafic pe portul de declanșare: un client din LAN, o sondă de monitorizare sau propriile verificări de ieșire ale serverului. Atunci maparea se deschide pentru acel singur host și se închide când traficul se oprește, așa că următorul partener extern eșuează din nou, în timp ce primul succes stă în jurnal și arată ca o dovadă.
Declanșarea este de obicei și pentru un singur host. Multe implementări permit doar unui singur dispozitiv intern să țină maparea o dată, ceea ce este exact greșit pentru un server care ar trebui să răspundă mai multor parteneri. Funcția a fost construită pentru aplicații care deschid o conexiune de control spre exterior și așteaptă date de intrare pe un al doilea port, și încă se potrivește acelei forme.
Ce mapează de fapt o redirecționare
O redirecționare este o intrare de traducere: port și protocol WAN către adresă și port interne. Are nevoie de un ascultător care rulează deja la celălalt capăt și are nevoie ca adresa internă să rămână unde este. Un lease DHCP care se mută pe altă mașină trimite fiecare tunel către hostul greșit, în tăcere, așa că creați rezervarea înainte de regulă.
| 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 |
Protocolul contează mai mult decât sugerează formularul. OpenVPN peste UDP are nevoie de o redirecționare UDP, WireGuard are nevoie de UDP, iar datele IPsec sosesc ca ESP, protocol IP 50, care nu are deloc porturi. Un formular de redirecționare care acceptă doar TCP sau UDP nu poate exprima asta, așa că IPsec are nevoie de passthrough sau de o mapare statică unu-la-unu în loc de o regulă de port.
Stratul de deasupra routerului
O redirecționare controlează doar traducerea care vă aparține. Dacă adresa WAN nu este a dumneavoastră, ceea ce este cazul în spatele NAT-ului de operator unde abonații partajează 100.64.0.0/10, cum este descris în RFC 6598, conexiunea de intrare nu ajunge niciodată la routerul dumneavoastră pentru că furnizorul a tradus primul. Nicio regulă de pe dispozitivul dumneavoastră nu poate repara acea ordine.
NAT-ul dublu este aceeași problemă în miniatură. Routerul dumneavoastră redirecționează către routerul ISP, care nu are o regulă potrivită și aruncă pachetul. Fie adăugați regula pe dispozitivul exterior, fie puneți dispozitivul exterior în modul punte și lăsați al dumneavoastră să țină adresa publică.
De aceea testul trebuie să vină din exterior. Un test din același LAN prin adresa publică depinde de suportul hairpin NAT și poate reuși sau eșua din motive fără legătură cu regula; un telefon pe date mobile, sau un prieten într-o altă rețea, este verificarea mai curată.
Limitați regula, apoi verificați ambele jumătăți
Redirecționați un port către o adresă. Un interval adăugat pentru că primele încercări au eșuat este calea prin care interfețele de administrare ajung pe internet, iar ascultătorul VPN nu are nevoie de pagina de administrare a routerului publicată alături.
Păstrați tot ce proteja deja acel ascultător: identitate prin certificat sau cheie, firewall-ul hostului, versiunile actuale ale pachetelor. O redirecționare lasă un pachet să intre; autentificarea decide dacă pachetul devine tunel, iar acestea sunt două eșecuri separate când ceva merge prost.
Verificarea are două jumătăți. Handshake-ul trebuie finalizat dintr-o rețea externă, apoi o resursă privată din spatele serverului trebuie să răspundă prin tunel. Redirecționarea admite conexiunea tunelului și nimic mai mult; rutarea și autorizarea pentru 10.8.0.0/24 sunt altă setare pe alt ecran.
Decideți cu trei întrebări
Trei întrebări rezolvă alegerea mai repede decât orice tabel comparativ:
- Se conectează ceva din exterior ca prim pachet? Atunci folosiți redirecționarea, sau un releu. Declanșarea nu se poate deschide fără trafic de ieșire care nu va exista niciodată.
- Trebuie gaura să supraviețuiască timpului de inactivitate? Atunci folosiți redirecționarea, pentru că o mapare declanșată se închide după propriul calendar.
- Adresa WAN este a dumneavoastră pentru publicare? Dacă nu, reparați stratul de deasupra înainte de a edita orice regulă.
Dacă răspunsul la toate trei este nu, ceea ce este cazul unui laptop care apelează singur un furnizor comercial, niciuna dintre reguli nu este necesară. Un client din spatele NAT funcționează pentru că își creează singur maparea cu stare, iar asta acoperă majoritatea oamenilor care citesc o pagină despre redirecționarea porturilor la miezul nopții.