VPN vārtejai nepieciešama IP pāradresācija: ko pārbaudīt
Vārteja var atbildēt uz savas adreses, kamēr starp saskarnēm nekas netiek pārsūtīts. Pārbaudiet pāradresāciju katrai saimei, pēc tam atgriešanās ceļu.
Jūsu klients var pingot vārtejas adresi, kamēr visi resursi aiz tās paliek nesasniedzami. Šis divu novērojumu pāris raksturo resursdatoru, kas runā ar jums, un maršrutētāju, kas nemaršrutē, un tie ir dažādas lomas tajā pašā mašīnā. Pāradresācija ir slēdzis starp tiem.
Abas lomas ir neatkarīgas, un arī abas adrešu saimes.
Atbilde uz savu adresi neko nepierāda
Kad pakete ir adresēta pašai vārtejai, vietējā kaudze to patērē un pāradresācijas lēmums netiek pieņemts. Tāpēc veiksmīgs ping uz tuneļa adresi vai pārvaldības saskarni jums pasaka, ka dēmons dzīvo un tunelis ir pacelts, bet neko nepasaka par satiksmi, kas paredzēta tīklam aiz kastes. Kodols savu pāradresācijas ceļu pārbauda tikai tām paketēm, kas nav adresētas tam.
Lasiet prasību kā lomu, nevis kā iestatījumu: šim resursdatoram ir jāpārvieto paketes starp divām saskarnēm. Klēpjdators, kuram tikai jāsasniedz attālināts tīkls, šo lomu nekad neuzņemas, un vietnes-uz-vietni galapunkts to vienmēr uzņemas. Šāda prasības lasīšana izskaidro, kāpēc strādājoša klienta konfigurācija neizdodas, kad to pārvieto uz vārteju.
Tas pats teikums attiecas uz ugunsmūri pirms pāradresācijas lēmuma, kuram ir sava politika par to, ko drīkst pārsūtīt.
Pārbaudiet katru adrešu saimi atsevišķi
IPv4 pāradresācija ir viens slēdzis, un IPv6 pāradresācija ir cits ar savu uzvedību katrā saskarnē. Pirmā ieslēgšana neko nepasaka par otro, un divkāršas kaudzes klients var sasniegt pusi tīkla, kamēr pārējais paliek tumšs. Tāpēc divi dažādu saišu klienti var nesaskanēt par to pašu vārteju. Pajautājiet, kuru saimi izmantoja nespējīgais klients, pirms maināt jebkuru iestatījumu. Apstipriniet abus, pirms secināt, ka maršrutēšanas projektējums ir nepareizs.
sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40
Daudzās distribūcijās izpildlaika vērtību tur ievietojusi pakalpojums vai konfigurācijas fails, tāpēc vienreizējas komandas veikta izmaiņa var pazust pārstartēšanas laikā. Atrodiet failu, kuram pieder iestatījums, pirms maināt izpildlaika vērtību.
Pāradresācija ir viena no četrām prasībām
Strādājošai pārsūtītai plūsmai vienlaikus vajag četras lietas: klientam jāzina, ka galamērķis ir aiz tuneļa, vārtejai jābūt ceļam uz priekšu, atbildēm jābūt ceļam atpakaļ, un ugunsmūrim jāatļauj satiksme. Avota tulkošana pieder šim projektējumam kā opcija, nevis noteikums, jo privātam maršrutētam tīklam ar simetriskiem ceļiem tā nav vajadzīga, bet asimetriskam parasti ir. Katra no četrām neizdodas neatkarīgi, tāpēc vienas labošana reti pabīda simptomu. Pierakstiet visas četras, pirms maināt jebkuru no tām.
Mākoņplatformas pievieno piekto apsvērumu. Dažas instancēs piemēro avota un galamērķa pārbaudes, kas izmet pārsūtītās paketes neatkarīgi no tā, kā konfigurēts viesa kodols. Tur autoritāte ir pašas platformas tīkla dokumentācija, nevis sysctl izvade VM iekšienē.
Testējiet no klienta, nevis no vārtejas
Tests, kas palaists pašas vārtejas čaulā, nešķērso nevienu tikko iespējotās pāradresācijas ceļa daļu. Ģenerējiet satiksmi no klienta, kuram ir problēma, un apstipriniet, ka tā sasniedz kaut ko aiz vārtejas, nevis pašu vārteju. Tas ir vienīgais tests, kas izmēģina mainīto lomu.
Turiet klausītāja noteikumus un pāradresācijas noteikumus atsevišķi galvā un izmaiņu žurnālā. VPN porta atvēršana ielaiž klientus pakalpojumā; tā nedod viņiem neko tīklā aiz tā, un abi izskatās vienādi ugunsmūra sarakstā, kas audzis gadiem.
Ja paketes ierodas un pakalpojums pēc tam noraida lietotāju, jūs jau esat pārsniedzis tīklu. Turpiniet ar lietojumprogrammas autorizāciju, nevis atkal paplašiniet pāradresācijas politiku.