Prievadų trigeris prieš prievadų persiuntimą namų VPN serveriui

Prievadų persiuntimas ir prievadų trigeris daugumoje namų maršrutizatorių yra tame pačiame meniu, todėl jie traktuojami kaip du vieno darbo būdai. Persiuntimas yra statinė taisyklė: į WAN prievadą ateinantis ryšys verčiamas fiksuotu vidiniu adresu ir prievadu, nesvarbu, ar dar kas nors vyksta. Trigeris yra sąlyginis: maršrutizatorius stebi išeinantį srautą ir atidaro įeinantį susiejimą tik po to, kai išeina atitinkamas ryšys. VPN serveris laukia, kol kas nors kitas prisijungs pirmas, todėl būtent ši sąlyga yra vienintelis dalykas, kurio jis niekada negali įvykdyti.

Dvi taisyklės su skirtingais gyvavimo ciklais

IPv4 NAT yra būsenos. Kai vidinis mazgas siunčia paketą laukan, maršrutizatorius sukuria susiejimą, kad atsakymai rastų kelią atgal; įeinantis paketas, kuris neatitinka jokio susiejimo, išmetamas, ir būtent šis elgesys laiko nepataisytą darbalaukį už interneto ribų. Persiuntimas yra nuolatinis vertimo įrašas, pridedamas rankiniu būdu. Trigeris yra laikina skylė, saugoma srauto modelio.

Praktinis skirtumas yra laikas. Persiuntimas egzistuoja nuo išsaugojimo momento, kol kas nors jį ištrina. Suveikusio trigerio susiejimas egzistuoja po to, kai trigeris suveikia, ir užsidaro pagal tuščiosios eigos laikmatį, vartotojų aparatinėje įrangoje matuojamą minutėmis, arba iškart perkraunant.

Nė vienas nėra saugesnis abstrakčiai. Persiuntimas nuolat atveria vieną prievadą; trigeris jį atveria tik po tam tikro išeinančio srauto. Paslaugai, kuri turi priimti pirmąjį paketą iš nepažįstamojo, tinka tik vienas iš dviejų.

Kodėl trigeris nepaskelbs serverio

VPN serveris pagal konstrukciją yra pasyvus. Partneris, ar tai nešiojamasis kompiuteris kavinėje, ar telefonas mobiliaisiais duomenimis, siunčia pirmąjį paketą, o maršrutizatorius neturi jam skirto susiejimo. Niekas viduje nepradėjo srauto į trigerio prievadą, todėl taisyklė niekada nesuveikia ir ryšys žūva prieš prasidedant rankos paspaudimui.

Ten, kur trigeris atrodo veikiąs, trigerio prievade srautą generuoja kažkas kita: klientas LAN tinkle, stebėjimo zondas arba paties serverio išeinančios patikros. Tada susiejimas atsidaro tam vienam mazgui ir užsidaro srautui sustojus, todėl kitas išorinis partneris vėl nepavyksta, o pirmoji sėkmė lieka žurnale ir atrodo kaip įrodymas.

Trigeris paprastai yra ir vieno mazgo. Daugelis realizacijų leidžia susiejimą vienu metu laikyti tik vienam vidiniam įrenginiui, o tai visiškai netinka serveriui, kuris turėtų atsakyti keliems partneriams. Funkcija buvo sukurta programoms, kurios atidaro valdymo ryšį laukan ir tikisi įeinančių duomenų antruoju prievadu, ir ji vis dar atitinka tą formą.

Ką persiuntimas iš tikrųjų susieja

Persiuntimas yra vienas vertimo įrašas: WAN prievadas ir protokolas į vidinį adresą ir prievadą. Jam reikia klausytojo, kuris jau veikia kitame gale, ir reikia, kad vidinis adresas liktų savo vietoje. DHCP nuoma, kuri persikelia į kitą mašiną, tyliai siunčia kiekvieną tunelį neteisingam mazgui, todėl rezervaciją sukurkite prieš taisyklę.

Protokolas svarbesnis, nei leidžia suprasti forma. OpenVPN per UDP reikalauja UDP persiuntimo, WireGuard reikalauja UDP, o IPsec duomenys ateina kaip ESP, IP protokolas 50, kuris iš viso neturi prievadų. Persiuntimo forma, priimanti tik TCP arba UDP, to negali išreikšti, todėl IPsec reikia passthrough arba statinio vienas-su-vienu susiejimo vietoj prievado taisyklės.

Sluoksnis virš jūsų maršrutizatoriaus

Persiuntimas valdo tik jums priklausantį vertimą. Jei WAN adresas nėra jūsų, o taip būna už operatoriaus NAT, kur abonentai dalijasi 100.64.0.0/10, kaip aprašyta RFC 6598, įeinantis ryšys niekada nepasieks jūsų maršrutizatoriaus, nes tiekėjas pirmas atliko vertimą. Jokia jūsų įrenginio taisyklė negali ištaisyti šios tvarkos.

Dvigubas NAT yra ta pati problema mažu mastu. Jūsų maršrutizatorius persiunčia į ISP maršrutizatorių, kuris neturi atitinkančios taisyklės ir išmeta paketą. Arba pridėkite taisyklę išoriniame įrenginyje, arba perjunkite išorinį įrenginį į tilto režimą ir leiskite savajam laikyti viešą adresą.

Štai kodėl bandymas turi ateiti iš išorės. Bandymas iš to paties LAN per viešą adresą priklauso nuo hairpin NAT palaikymo ir gali pavykti arba nepavykti dėl su taisykle nesusijusių priežasčių; telefonas mobiliaisiais duomenimis ar draugas kitame tinkle yra švaresnė patikra.

Apribokite taisyklę, tada patikrinkite abi puses

Persiųskite vieną prievadą į vieną adresą. Diapazonas, pridėtas todėl, kad pirmieji bandymai nepavyko, yra kelias, kuriuo valdymo sąsajos patenka į internetą, o VPN klausytojui nereikia šalia paskelbto maršrutizatoriaus administravimo puslapio.

Išsaugokite viską, kas jau saugojo tą klausytoją: tapatybę pagal sertifikatą ar raktą, mazgo užkardą, naujausias paketų versijas. Persiuntimas įleidžia paketą; autentifikacija nusprendžia, ar paketas taps tuneliu, ir tai yra dvi atskiros klaidos, kai kas nors nepavyksta.

Patikra turi dvi puses. Rankos paspaudimas turi įvykti iš išorinio tinklo, o tada privatus išteklius už serverio turi atsakyti per tunelį. Persiuntimas įleidžia tunelio ryšį ir nieko daugiau; maršrutizavimas ir autorizacija 10.8.0.0/24 tinklui yra kitas nustatymas kitame ekrane.

Nuspręskite trimis klausimais

Trys klausimai išsprendžia pasirinkimą greičiau nei bet kokia palyginimo lentelė:

• Ar kas nors prisijungia iš išorės kaip pirmasis paketas? Tada naudokite persiuntimą arba rele. Trigeris negali atsidaryti be išeinančio srauto, kurio niekada nebus.
• Ar skylė turi išgyventi tuščiosios eigos laiką? Tada naudokite persiuntimą, nes suveikusio trigerio susiejimas užsidaro pagal savo grafiką.
• Ar WAN adresas jūsų, kad galėtumėte jį paskelbti? Jei ne, pataisykite sluoksnį aukščiau prieš redaguodami bet kokią taisyklę.

Jei atsakymas į visus tris yra ne, o tai yra nešiojamojo kompiuterio, kuris pats skambina komerciniam tiekėjui, atvejis, nereikia nė vienos taisyklės. Klientas už NAT veikia todėl, kad pats sukuria būsenos susiejimą, ir tai apima daugumą žmonių, kurie vidurnaktį skaito puslapį apie prievadų persiuntimą.