VPN inter ejoj funkcias nur unuflanke: du malsamaj paneoj
Respondo, kiu neniam revenas, kaj konekto, kiu estis rifuzita, estas du malsamaj paneoj. Komparu regularon, enkursigadon kaj la fontadreson, kiun la servilo efektive vidas.
Ejo A atingas B, B ne povas atingi A, kaj la tunelo aspektas bone en ambaŭ direktoj. Antaŭ ol tuŝi la tunelon, decidu, kiun paneon vi efektive havas. Nova konekto komencita ĉe B, kiu estas rifuzata, kaj respondo al konekto komencita ĉe A, kiu neniam alvenas, produktas similajn plendojn kaj tute malsamajn diagnozojn. Unu estas problemo pri regularo aŭ itinero sur la vojo; la alia estas problemo pri revena vojo aŭ stato por trafiko, kiu jam estis permesita.
Tiu distingo decidas, kiujn komandojn indas lanĉi.
Du paneoj, kiuj aspektas identaj
En la unua kazo la gastiganto de B sendas SYN al A, kaj nenio revenas. En la dua la gastiganto de A sukcese malfermas seancon kaj la respondo malaperas sur la revena vojo. Ambaŭ uzantoj diras, ke la ligo estas unudirekta, kaj ambaŭ priskribas paketon, kiu malaperis, do la priskribo sola ne povas apartigi ilin.
Demandu, kiu flanko komencis la malsukcesan provon. Tiu unu fakto forigas duonon de la eblaj kaŭzoj.
Poste kontrolu, ke la testo uzis la samajn gastigantojn kaj la saman servon la tutan tempon. Ping de unu flanko kaj konekto al kunhava dosierujo de la alia testas du malsamajn aferojn, kaj diagnozo farita de la kluzo povas elekti tuneladreson, kiun neniu uzanttrafiko iam uzas.
Unua kazo: la revena vojo mankas
Fora servilo, kiu respondas per alia defaŭlta kluzo, povas ricevi la peton kaj enkursigi la respondon aliloken. Fajroŝirmiloj, kiuj konservas staton, tiam forĵetas la nesimetrian respondon ĉar ĝi ne kongruas kun establiĝinta fluo, kio aspektas ĝuste kiel direkto, kiu neniam funkciis. Traduko aldonas alian version: la celo vidas tradukitan fonton kaj respondas al ĝi, do regulo skribita por la origina adreso neniam kongruas.
Kontrolu la adreson, kiun la celo efektive vidas post la traduko, kaj la revenan itineron por tiu adreso anstataŭ por la origina subreto.
Dua kazo: la regularo neniam permesis ĝin
La mala kazo estas pli simpla kaj pli ofta, ol ĝi aspektas: unu oficejo devas konsumi centran servon kaj neniam komenci konektojn en la centron. Tiu nesimetrio estas intenca alirdeciso, kaj la tunelo funkcias kiel projektite. Legu la alirregularon antaŭ ol ŝanĝi iun ajn agordon de la tunelo. La dokumento, ne la paketkaptado, diras, kiun direkton oni intencis. Kaptado povas montri nur tion, kio okazis, ne tion, kio estis permesita.
Se la duflanka iniciato vere necesas, aldonu la permeson por la konkreta servo per la subtenata regulkompleto de la platformo. Fari ĉiun subreton reciproke fidinda por ripari unu aplikaĵon ŝanĝas mallarĝan postulon al larĝa permeso, kaj tiu interŝanĝo malofte estas reviziata poste.
Komparu antaŭ kaj post sur la samaj gastigantoj
Observu ambaŭ finojn de la sama provo, ne du apartajn provojn. Kaptu ĉe la kluzo de la komencanta gastiganto kaj ĉe la celo, poste komparu, kio eniris, kio eliris kaj kiun adreson la fora flanko vidis.
tcpdump -ni any host 10.20.30.40 and port 445 conntrack -L | grep 10.20.30.40 ip route get 10.20.30.40 swanctl --list-sas
Se la kapto ĉe la celo montras la peton kun neatendita fontadreso, la respondo kuŝas en traduko aŭ enkursigado, ne en la sekureca regularo de la tunelo. Se la celo tute ne montras peton, la paketo neniam transiris la protektitan vojon.
Post korekto ripetu la identan teston de la identa gastiganto kaj konfirmu, ke senrilata aliro estas ankoraŭ rifuzata. Tunela stato “established” subtenas neniun el la du konkludoj sole.