VPN uz maršrutētāja vai porta pāradresācija: kas uzvar?

Maršrutētājs pats pabeidz VPN, un vecs pāradresācijas noteikums joprojām sūta to pašu UDP portu uz mašīnu LAN tīklā. Tikai viens no tiem var būt īstais galapunkts, un kodols starp tiem neizlemj. Galamērķa tulkošana pārraksta paketi pirms vietējā pakalpojuma izsaukšanas, tāpēc VPN process gaida satiksmi, kas jau nosūtīta citur. Uzdevums ir izlemt, kam pieder ports, un pēc tam saskaņot noteikumus.

Viens ports, divi apgalvoti īpašnieki

VPN serverim, kas darbojas maršrutētājā, nepieciešama ienākošā atļauja, kas ved uz tā paša ligzdu. Tā paša porta galamērķa NAT ieraksts ved pavisam citur: uz LAN adresi un pāradresācijas lēmumu. Tie ir dažādi galapunkti ar dažādiem žurnāliem un dažādiem atteices režīmiem. Ierastā pazīme ir tā, ka viena adrešu saime strādā, bet otra ne, jo atlikušais ieraksts tika rakstīts vienai saimei un nekad netika pārskatīts.

Pirms rediģēšanas pierakstiet prasību: saime, ārējā adrese, transports, ports un tulkotais mērķis.

Tulkošana notiek pirms vietējās pārbaudes

Galamērķa NAT maina paketes mērķi pirms maršrutēšanas posmā, pirms kodols izvēlas starp vietējo piegādi un pāradresāciju. Kad mērķis kļūst par LAN resursdatoru, pakete iet pāradresācijas ceļu. Ievades noteikumi maršrutētāja paša ligzdai nekad netiek izskatīti, tāpēc VPN žurnāls paliek tukšs, kamēr klients gaida.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Šī secība ir viss mehānisms, un ierīču saskarnes to slēpj aiz izvēles rūtiņām to nemainot. Paketes ceļu joprojām nosaka galamērķa īpašnieks.

Ja LAN resursdators ir paredzētais galapunkts, pāradresācija ir pareiza, un maršrutētājam nevajadzētu arī klausīties šajā portā.

Paturiet vienu kartējumu un noņemiet otru

Uzskaitiet NAT ierakstus šim portam un saimei un izvēlieties izdzīvojušo:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

TCP ieraksts ar to pašu numuru UDP kļūmei nav nozīmīgs, un to uzskatīšana par vienu objektu noved pie nepareizā noteikuma dzēšanas. Kad vietējai ligzdai vajadzētu uzvarēt, pretrunīgā kartējuma īpašnieks noņem vai pārraksta tieši šo ierakstu, un ienākošā atļauja maršrutētāja pašam portam paliek savā vietā. Nesaistītām pāradresācijām, pārvaldības ceļam un noteikumu kopas eksemplāram visiem jāpārdzīvo šīs izmaiņas.

Ja VPN dzīvo atsevišķā resursdatorā, pāradresācija ir pareizais objekts. Pakalpojumam konteinerā vai virtuālajā mašīnā var būt nepieciešams publicēts ports pat tad, ja kaste tiek saukta par maršrutētāju, tāpēc izsekojiet ligzdu un tās nosaukumtelpu, nevis etiķeti uz korpusa.

Apstipriniet īpašnieku no ārpuses

Pārbaudiet katru saimi atsevišķi, jo IPv6 savienojums, kas beidzas maršrutētājā, neko neizsaka par IPv4 savienojumu, ko novirza novecojis noteikums. Lasiet saņēmēja pakalpojuma žurnālu, lai redzētu, kurš galapunkts atbildēja, un uzskatiet klienta veiksmes ziņojumu par vāju pierādījumu. Jēgpilnai pārbaudei nepieciešama jauna plūsma. Nosūtiet zondi no ārēja resursdatora ar nc -zvu 203.0.113.7 1194 un lasiet uzvarētāja žurnālu ar journalctl -u openvpn@server -n 20. Maršrutētāja klausītājs pats reģistrē savienojumu, kamēr LAN resursdators to reģistrē savā pakalpojumā.

Savienojumu izsekošana notur esošās plūsmas to sākotnējā kartējumā, tāpēc izveidota sesija var pārdzīvot noteikumu, ko tikko izlabojāt.

Kad paredzētais galapunkts atbild ar savām parastajām identitātes pārbaudēm, pārbaudiet privātu resursu aiz tuneļa. Sasniegt ārējo klausītāju ir tikai pirmais solis; iekšējā maršrutēšana un lietojumprogrammas autorizācija ir atsevišķi rezultāti.