Kiinteät UDP-portit voivat ohittaa portin edelleenohjauksen, mutta eivät jokaista NAT:ia

Kaksi kotireititintä, ei yhtään edelleenohjattua porttia ja VPN, joka silti joskus yhdistyy. UDP sallii sen, koska palomuuri päästää läpi paketin, jonka se voi sovittaa koneen jo aloittamaan virtaukseen. Se on ehdollinen kikka, ei ominaisuus, ja ehdot on helppo luetella, kun tietää, mitä palomuuri vertaa. Ne ovat myös syy siihen, miksi samanlaiset profiilit käyttäytyvät eri verkoissa eri tavalla.

Vertailu, jonka palomuuri tekee

Jokainen lähtevä datagrammi luo lyhytaikaisen merkinnän: lähdeosoite, lähdeportti, kohdeosoite, kohdeportti. Kaikki saapuva, joka täsmää merkintään, käsitellään vastauksena ja päästetään läpi. Saapuvan liikenteen säännöt eivät vaikuta tähän.

Kysymys ei siis ole siitä, päästääkö palomuuri vastapuolen sisään. Vaan siitä, näyttääkö vastapuolen paketti vastaukselta, jota merkintä odottaa. Muuta yksi kenttä tuosta neliosaisesta monikosta ja paketista tulee vieras. Siksi toimiva kokoonpano voi hajota, kun vain portin numero muuttuu, ja siksi sama portti voi toimia yhdellä reitittimellä ja epäonnistua seuraavalla.

Kiinnitä paikallinen lähdeportti, niin sama numero näkyy vaihdon molemmilla puolilla. Siinä koko mekanismi, ja se selittää, miksi kikka on hauras eikä salaperäinen.

Yhden portin kiinnittäminen kummassakin päässä

OpenVPN:n oletus-UDP-portti on 1194, ja lport asettaa lähdeportin, josta se lähettää. Kiinnitä molemmat vastapuolet, niin kummankin lähtevä monikko osoittaa porttiin, jota toinen kuuntelee:

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

Tämä toimii vain niin kauan kuin mikään niiden välinen reititin ei kirjoita lähdeporttia uudelleen. Kun paketit näkyvät kaappauksessa mutta tunnelia ei nouse, uudelleenkirjoitus on ensimmäinen epäilty.

Missä monikko lakkaa täsmäämästä

Kohdekohtaisesti kartoittava NAT antaa kummallekin vastapuolelle eri ulkoisen portin. Osoite, joka vastapuolellesi sanottiin käytettäväksi, ei ole se osoite, joka hänet tavoittaa, joten saapuva paketti ei täsmää mihinkään ja hylätään hiljaa.

Operaattoritason käännös, pinottu NAT ja porttien satunnaistus päättyvät kaikki samalla tavalla. Samoin mikä tahansa välilaite, joka kirjoittaa portit uudelleen mutta jättää osoitteet rauhaan.

Virtaustransporteilla menee huonommin. TCP-kättely seurataan vaihe vaiheelta, joten TCP-pohjaista VPN:ää ei voi lainkaan lävistää tällä tavalla ja se tarvitsee kuuntelijan jonnekin reitille.

Yleensä toinen puoli pettää ensin

Käytännössä kaksi verkkoa käyttäytyvät harvoin samoin. Yksi reititin voi jakaa ennustettavaa kartoitusta, kun taas toinen jakaa portit kohteen mukaan, ja tuloksena on kokoonpano, joka toimii kahden kodin välillä ja epäonnistuu matkapuhelinverkosta. Toisiaan vastaan puhuvat raportit kuvaavat yleensä kahta eri reititinparia. Kumpikaan kirjoittaja ei ole väärässä, eikä kumpikaan tulos yleisty.

Selvitä, kumpi puoli pudotti paketin, ennen kuin kosket profiileihin. Kaappaukset molemmista päistä ratkaisevat sen yhdellä yrityksellä: datagrammit, jotka lähtevät A:sta eivätkä koskaan saavu B:hen, tarkoittavat, että virtaus kirjoitettiin matkalla uudelleen, kun taas datagrammit, jotka saapuvat B:hen ilman että vastausta tulee takaisin, tarkoittavat, ettei palomuuri hyväksynyt niitä liittyviksi.

Kaksi julkisen IPv6-osoitteen vastapuolta kiertää koko ongelman. Ilman käännöstä ei ole mitään sovitettavaa, joten palomuurisääntö, joka nimeää vastapuolet, riittää ja suunnittelu lakkaa riippumasta reitittimen käytöksestä.

Milloin lopettaa yrittäminen

Julkisen osoitteen isäntä on luotettava vastaus. Se voi päättää tunnelin molempien vastapuolten puolesta tai yksinkertaisesti auttaa heitä löytämään toistensa nykyisen ulkoisen osoitteen, ja molemmat järjestelyt toimivat riippumatta siitä, mitä NAT:t tekevät. Hallittu päällekkäisverkko tarjoaa saman koordinoinnin, jos käytäntö sen sallii.

Mikään näistä ei tarvitse pois päältä kytkettyä palomuuria. Suojauksen sammuttaminen suoran yhteyden voittamiseksi heittää pois syyn, jonka vuoksi suora yritys oli houkutteleva, ja jättää koneen avoimeksi koko testin ajaksi.

Kokeile ensin suoraa järjestelyä ja kirjaa sitten, mitä näit. NAT:n käytös ja sen näyttänyt kaappaus ovat arvokkaampia kuin se porttipari, johon lopulta päädyit, koska seuraava verkko on erilainen. OpenVPN 2.6 -käsikirja dokumentoi lport ja remote-valinnat, joista tämä riippuu.