Fiksēti UDP porti var apiet portu pāradresāciju, bet ne katru NAT

Divi mājas maršrutētāji, neviena pāradresēta porta, un VPN, kas dažkārt tomēr pieslēdzas. UDP to pieļauj, jo ugunsmūris ielaidīs paketi, ko tas var saskaņot ar plūsmu, kuru iekārta jau ir sākusi. Tas ir nosacīts triks, nevis funkcija, un nosacījumus ir viegli uzskaitīt, kad zini, ko ugunsmūris salīdzina. Tie ir arī iemesls, kāpēc identiski profili dažādos tīklos uzvedas atšķirīgi.

Salīdzinājums, ko veic ugunsmūris

Katrs izejošais datagramma izveido īslaicīgu ierakstu: avota adrese, avota ports, galamērķa adrese, galamērķa ports. Viss, kas atnāk un atbilst ierakstam, tiek uzskatīts par atbildi un tiek laists cauri. Ienākošās satiksmes noteikumi šeit neko nenosaka.

Tātad jautājums nav par to, vai ugunsmūris ielaiž partneri. Jautājums ir par to, vai partnera pakete izskatās kā atbilde, uz kuru ieraksts gaida. Ja nomaina vienu lauku šajā četrdaļu kortežā, pakete kļūst sveša. Tāpēc strādājoša konfigurācija var salūzt, kad mainās tikai porta numurs, un tāpēc viens un tas pats ports var strādāt vienā maršrutētājā un neizdoties nākamajā.

Nofiksē vietējo avota portu, un tas pats numurs parādīsies abās apmaiņas pusēs. Tas ir viss mehānisms, un tas izskaidro, kāpēc triks ir trausls, nevis noslēpumains.

Viena porta nofiksēšana katrā galā

OpenVPN noklusējuma UDP ports ir 1194, un lport nosaka avota portu, no kura tas sūta. Nofiksē abus partnerus, un katra izejošā korteža norādīs uz portu, kurā klausās otrs:

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

Tas darbojas tikai tik ilgi, kamēr neviens maršrutētājs starp tiem nepārraksta avota portu. Kad paketes parādās uzņēmumā, bet tunelis neceļas, pārrakstīšana ir pirmais aizdomās turamais.

Kur korteža pārstāj atbilst

NAT, kas kartē pēc galamērķa, katram partnerim dod citu ārējo portu. Adrese, ko partnerim lika izmantot, nav tā adrese, kas viņu sasniedz, tāpēc ienākošā pakete neatbilst nekam un tiek klusi izmesta.

Operatora līmeņa tulkošana, slāņotais NAT un portu randomizācija beidzas vienādi. Tāpat jebkura starpmezgla kaste, kas pārraksta portus, bet adreses atstāj mierā.

Straumes transportiem iet sliktāk. TCP rokasspiediens tiek izsekots soli pa solim, tāpēc uz TCP balstītu VPN šādi vispār nevar izsist cauri, un tam vajag klausītāju kaut kur ceļā.

Parasti viena puse neizdodas pirmā

Praksē abi tīkli reti uzvedas vienādi. Viens maršrutētājs var dot paredzamu kartējumu, bet otrs – portus pēc galamērķa, un rezultāts ir konfigurācija, kas darbojas starp divām mājām un neizdodas no mobilā tīkla. Savstarpēji pretrunīgi ziņojumi parasti apraksta divus dažādus maršrutētāju pārus. Neviens autors nekļūdās, un neviens rezultāts nav vispārināms.

Pirms aiztiec profilus, noskaidro, kura puse nometa paketi. Uzņēmumi abos galos to izšķir vienā mēģinājumā: datagrammas, kas iziet no A un nekad nesasniedz B, nozīmē, ka plūsma tika pārrakstīta ceļā, bet datagrammas, kas sasniedz B bez atbildes, nozīmē, ka ugunsmūris tās nepieņēma kā saistītas.

Divi partneri ar publiskām IPv6 adresēm apiet visu problēmu. Bez tulkošanas nav ko saskaņot, tāpēc pietiek ar ugunsmūra noteikumu, kas nosauc partnerus, un dizains pārstāj būt atkarīgs no maršrutētāja uzvedības.

Kad pārtraukt mēģinājumus

Resursdators ar publisku adresi ir uzticamā atbilde. Tas var izbeigt tuneli abiem partneriem vai vienkārši palīdzēt viņiem atrast otra pašreizējo ārējo adresi, un abi risinājumi darbojas neatkarīgi no tā, ko dara NAT. Pārvaldīts pārklājums nodrošina tādu pašu koordināciju, ja politika to atļauj.

Nevienam no šiem nav vajadzīgs izslēgts ugunsmūris. Aizsardzības izslēgšana, lai uzvarētu tiešo savienojumu, atmet iemeslu, kāpēc tiešais mēģinājums bija pievilcīgs, un atstāj iekārtu atvērtu visu testa laiku.

Vispirms izmēģini tiešo risinājumu, tad pieraksti, ko redzēji. NAT uzvedība un uzņēmums, kas to parādīja, ir vērtīgāki par portu pāri, ko beigās izmantojāt, jo nākamais tīkls būs citāds. OpenVPN 2.6 rokasgrāmata dokumentē lport un remote opcijas, no kurām tas ir atkarīgs.