Faste UDP-porte kan springe portforwarding over, men ikke enhver NAT

To hjemmeroutere, ingen videresendte porte og en VPN, der alligevel nogle gange forbinder. UDP tillader det, fordi en firewall lukker en pakke ind, som den kan matche mod en strøm, maskinen allerede har startet. Det er et betinget trick, ikke en funktion, og betingelserne er nemme at angive, når man ved, hvad firewallen sammenligner. De er også grunden til, at identiske profiler opfører sig forskelligt på forskellige netværk.

Den sammenligning en firewall foretager

Hver udgående datagram opretter en kortlivet post: kildeadresse, kildeport, destinationsadresse, destinationsport. Alt, der ankommer og matcher posten, behandles som et svar og lukkes igennem. Regler for indgående trafik spiller ingen rolle.

Så spørgsmålet er ikke, om firewallen lukker peer'en ind. Det er, om peer'ens pakke ser ud som det svar, posten venter på. Ændr ét felt i den firedelte tuple, og pakken bliver en fremmed. Derfor kan en fungerende opsætning gå i stykker, når kun portnummeret ændres, og derfor kan den samme port virke på én router og fejle på den næste.

Låses den lokale kildeport fast, vises det samme nummer på begge sider af udvekslingen. Det er hele mekanismen, og det forklarer, hvorfor tricket er skrøbeligt snarere end mystisk.

Fastlåsning af én port i hver ende

OpenVPNs standard-UDP-port er 1194, og lport sætter den kildeport, der sendes fra. Lås begge peers fast, og begge parters udgående tuple peger på en port, som den anden lytter på:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

Det virker kun, så længe ingen router mellem dem omskriver kildeporten. Når pakker dukker op i en optagelse, men ingen tunnel rejser sig, er omskrivningen den første mistænkte.

Hvor tuple'en holder op med at matche

En NAT, der mapper pr. destination, giver hver peer en forskellig ekstern port. Den adresse, din peer fik besked om at bruge, er ikke den adresse, der når den, så den indgående pakke matcher intet og kasseres i stilhed.

Operatørniveau-oversættelse, stablet NAT og portrandomisering ender alle samme sted. Det gør enhver mellemboks, der omskriver porte og lader adresserne være.

Strømtransporter er værre stillet. Et TCP-håndtryk følges trin for trin, så en TCP-baseret VPN kan slet ikke hules på denne måde og har brug for en lytter et sted på vejen.

Den ene side fejler som regel først

I praksis opfører de to netværk sig sjældent ens. Én router kan udlevere en forudsigelig mapping, mens den anden udleverer porte pr. destination, og resultatet er en konfiguration, der virker mellem to hjem og fejler fra et mobilnetværk. Indberetninger, der modsiger hinanden, beskriver som regel to forskellige par af routere. Ingen af forfatterne tager fejl, og ingen af resultaterne kan generaliseres.

Find ud af, hvilken side der droppede pakken, før du rører profilerne. Optagelser i begge ender afgør det i ét forsøg: datagrammer, der forlader A og aldrig når B, betyder, at strømmen blev omskrevet undervejs, mens datagrammer, der når B uden at noget svar kommer tilbage, betyder, at firewallen ikke accepterede dem som relaterede.

To peers med offentlige IPv6-adresser går uden om hele problemet. Uden oversættelse er der intet at matche, så en firewallregel, der navngiver peerne, er nok, og designet holder op med at afhænge af routeradfærd.

Hvornår man skal holde op

En vært med en offentlig adresse er det pålidelige svar. Den kan afslutte tunnelen for begge peers eller blot hjælpe dem med at finde hinandens aktuelle eksterne adresse, og begge arrangementer virker, uanset hvad NAT'erne gør. Et administreret overlay giver samme koordinering, hvis politikken tillader det.

Intet af dette har brug for en deaktiveret firewall. At slå beskyttelsen fra for at vinde den direkte forbindelse kaster grunden til, at det direkte forsøg var attraktivt, væk, og det efterlader maskinen åben i hele testens varighed.

Prøv det direkte arrangement først, og skriv så ned, hvad du så. NAT-adfærden og den optagelse, der viste den, er mere værd end det portpar, du endte med at bruge, fordi det næste netværk vil være anderledes. OpenVPN 2.6-manualen dokumenterer lport og de remote-muligheder, dette afhænger af.