SSH al la publika IP de la WireGuard-servilo malsukcesas en Windows

Tuneloj, kiuj leviĝas dum SSH al la publika adreso de la servilo ĉesas funkcii, aspektas kiel servilo, kiu rifuzas la konekton. En Windows la pli verŝajna kaŭzo estas loka: AllowedIPs de plena tunelo je /0 ŝaltas limigajn fajroŝirmajn regulojn, kiuj permesas la propran transporton de la tunelo kaj tre malmulte alian. Ĉifritaj pakaĵoj, kiuj atingas tiun adreson, diras nenion pri tio, ĉu aparta TCP-konekto al la sama adreso rajtas eliri.

Apartigu la publikan adreson de la finpunkto disde ĝia interna tunela adreso antaŭ ol tuŝi la liston de samtavolanoj. Preskaŭ ĉiu provo ripari tion per redaktado de AllowedIPs malfortigas la politikon anstataŭ igi la itineron ĝusta.

Enkursiga permeso kaj fajroŝirma permeso estas malsamaj

Itinero decidas, kien pakaĵo estus sendita, kaj fajroŝirma regulo decidas, ĉu ĝi rajtas esti sendita entute. Aldoni itineron por la publika IP de la finpunkto do produktas vojon, kiun la filtrilo ankoraŭ povas bloki, kaj ĝuste tiun konfuzon kreas ĉi tiu simptomo. En Windows la filtrilo estas parto de la efektivigo, ne aldonaĵo, do neniu itinera ero ŝanĝas ĝin. La du decidoj estas apartaj ankaŭ aliloke, kvankam la defaŭltoj malsamas.

Tial traceroute al la finpunkto povas sukcesi dum SSH-provo malsukcesas. La unuan portas la servo, kiu posedas la escepton, la duan ne.

Kion /0 faras en Windows

Kun sola samtavolano, kies permesitaj adresoj kovras la tutan IPv4-spacon, WireGuard for Windows aplikas limigan fajroŝirman sintenon, kiu blokas trafikon, kiu alie elirus ekster la tunelon. La propra transporto de la tunela servo estas permesita, ĉar la VPN alie ne povus funkcii. Alia aplikaĵo al la sama publika adreso ne ricevas tian permeson, ĉar la escepto apartenas al la transporto, ne al la adreso. Retaj notoj pri Windows priskribas ĉi tiun konduton kaj la rilatan regilon en la redaktilo.

Tiuj reguloj estas la mekanismo malantaŭ la esprimo kill switch. Ili aktiviĝas per la formo de la agordo, ne per markobutono tiel nomata.

Esceptoj ŝanĝas la protektan modelon

Anstataŭigi /0 per du duondefaŭltaj prefiksoj estas la dokumentita maniero konservi vastan enkursigadon sen la limiga semantiko, kaj ĝi estas alia protekta modelo, ne pli mallonga skribo. Subtrahi la finpunktan adreson de la permesitaj prefiksoj estas la alia ofta solvo, kiu longigas la liston kaj ankaŭ ŝanĝas, kiuj reguloj aktiviĝas. Neniu el ili estas loka ŝanĝo kun loka efiko. Ĉiu movas la limon por ĉiu fluo en la maŝino, ne nur por la konekto, kiun vi riparis.

Kie rekta publika SSH estas vere bezonata, la posedanto de la profilo devas desegni kaj la eksteran itineron kaj ĝian fajroŝirman permeson, kaj decidi, kio okazas al nerilata trafiko kiam la tunelo falas. Aparta revizio de IPv4 kaj IPv6 ankaŭ apartenas al tio, ĉar la reguloj esprimiĝas laŭ familio. Vasta pretervojo aldonita por savi unu administran seancon kutime malkaŝas pli ol la seancon.

Testu la administran vojon, kiun vi elektis

Unue decidu, ĉu administrado vojaĝu ene de la tunelo aŭ ekster ĝi, poste testu tiun elekton anstataŭ ambaŭ samtempe. La subaj komandoj kontrolas la adresojn de la kliento, la staton de la samtavolano kaj konekton al ĉiu celo. Rulu ilin el la Windows-kliento dum la tunelo staras.

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

Sukcesa SSH al la interna adreso pruvas, ke la tunelo portas administran trafikon kaj ke la propra fajroŝirmo de la servilo akceptas ĝin el la samtavolana gamo. Malsukceso ĉe ambaŭ celoj estas problemo ĉe la servilo aŭ ĉe la ŝlosilo, ne ĉe Windows-enkursigado. Se la interna adreso funkcias kaj la ekstera ne, la loka fajroŝirma sinteno faras ĝuste tion, por kio ĝi estis desegnita. Legu la tri rezultojn en tiu ordo antaŭ ol redakti profilon.

Notu la administran vojon, la uzitan adreson kaj la konduton kiam la tunelo estas mallevita. Tiu noto estas tio, kio malhelpas la sekvan personon vastigi la pretervojon por ŝpari kvin minutojn.