Vaste UDP-poorten kunnen portforwarding overslaan, maar niet elke NAT

Twee thuisrouters, geen doorgestuurde poorten, en een VPN die soms toch verbindt. UDP staat dat toe, omdat een firewall een pakket toelaat dat hij kan matchen met een stroom die de machine al is begonnen. Het is een voorwaardelijke truc, geen functie, en de voorwaarden zijn makkelijk te noemen als je weet wat de firewall vergelijkt. Ze zijn ook de reden dat identieke profielen zich op verschillende netwerken anders gedragen.

De vergelijking die een firewall maakt

Elk uitgaand datagram maakt een kortlevende vermelding: bronadres, bronpoort, bestemmingsadres, bestemmingspoort. Alles wat binnenkomt en bij de vermelding past, wordt als antwoord behandeld en doorgelaten. Regels voor inkomend verkeer spelen daarbij geen rol.

De vraag is dus niet of de firewall de peer binnenlaat. Ze is of het pakket van de peer lijkt op het antwoord waar de vermelding op wacht. Verander één veld van die vierdelige tuple en het pakket wordt een vreemde. Daarom kan een werkende opstelling breken wanneer alleen het poortnummer verandert, en daarom kan dezelfde poort op de ene router werken en op de volgende falen.

Zet de lokale bronpoort vast, en hetzelfde nummer verschijnt aan beide kanten van de uitwisseling. Dat is het hele mechanisme, en het verklaart waarom de truc fragiel is in plaats van mysterieus.

Eén poort aan elk uiteinde vastzetten

De standaard UDP-poort van OpenVPN is 1194, en lport stelt de bronpoort in waarvandaan hij verstuurt. Zet beide peers vast en de uitgaande tuple van elk wijst naar een poort waarop de ander luistert:

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

Dat werkt alleen zolang geen router ertussen de bronpoort herschrijft. Wanneer pakketten in een capture verschijnen maar er geen tunnel opkomt, is de herschrijving de eerste verdachte.

Waar de tuple niet meer past

Een NAT die per bestemming mapt, geeft elke peer een andere externe poort. Het adres dat je peer te horen kreeg te gebruiken is niet het adres dat hem bereikt, dus het inkomende pakket past op niets en wordt stil weggegooid.

Carrier-grade-vertaling, gestapelde NAT en poortrandomisatie eindigen allemaal hetzelfde. Zo ook elke middenbox die poorten herschrijft en de adressen met rust laat.

Streamtransporten zijn slechter af. Een TCP-handshake wordt stap voor stap gevolgd, dus een op TCP gebaseerde VPN kan op deze manier helemaal niet worden doorgeprikt en heeft ergens op het pad een luisteraar nodig.

Meestal faalt één kant eerst

In de praktijk gedragen de twee netwerken zich zelden hetzelfde. De ene router geeft misschien een voorspelbare mapping terwijl de andere poorten per bestemming geeft, en het resultaat is een configuratie die tussen twee huishoudens werkt en vanaf een mobiel netwerk faalt. Rapporten die elkaar tegenspreken beschrijven meestal twee verschillende paren routers. Geen van beide auteurs heeft ongelijk, en geen van beide resultaten is te generaliseren.

Zoek uit welke kant het pakket heeft laten vallen voordat je de profielen aanraakt. Captures aan beide uiteinden beslechten het in één poging: datagrammen die A verlaten en B nooit bereiken betekenen dat de stroom onderweg is herschreven, terwijl datagrammen die bij B aankomen zonder dat er een antwoord terugkomt betekenen dat de firewall ze niet als verwant heeft geaccepteerd.

Twee peers met openbare IPv6-adressen omzeilen het hele probleem. Zonder vertaling is er niets te matchen, dus een firewallregel die de peers noemt is genoeg en het ontwerp is niet langer afhankelijk van routergedrag.

Wanneer stoppen met proberen

Een host met een openbaar adres is het betrouwbare antwoord. Hij kan de tunnel voor beide peers beëindigen, of hen gewoon helpen elkaars huidige externe adres te vinden, en beide opstellingen werken wat de NAT's ook doen. Een beheerde overlay biedt dezelfde coördinatie als het beleid het toestaat.

Geen van deze heeft een uitgeschakelde firewall nodig. Bescherming uitzetten om de directe verbinding te winnen gooit de reden weg waarom de directe poging aantrekkelijk was, en het laat de machine open voor de duur van de test.

Probeer eerst de directe opstelling en noteer dan wat je zag. Het NAT-gedrag en de capture die het liet zien zijn meer waard dan het poortpaar dat je uiteindelijk gebruikte, omdat het volgende netwerk anders zal zijn. De OpenVPN 2.6-handleiding documenteert lport en de remote-opties waar dit van afhangt.