Site-to-site VPN töötab ainult ühes suunas: kaks erinevat riket

Asukoht A jõuab B-ni, B ei jõua A-ni ja tunnel näeb mõlemas suunas korras välja. Enne tunneli puutumist otsustage, milline rike teil tegelikult on. B-l algatatud uus ühendus, mis lükatakse tagasi, ja A-l algatatud ühenduse vastus, mis ei saabu kunagi, tekitavad sarnaseid kaebusi ja täiesti erinevaid diagnoose. Üks on poliitika või marsruudi probleem teel; teine on tagasitee või oleku probleem liiklusele, mis oli juba lubatud.

See eristus otsustab, milliseid käske tasub käivitada.

Kaks riket, mis näevad identsed välja

Esimesel juhul saadab B host A-le SYN-i ja midagi ei tule tagasi. Teisel juhul avab A host sessiooni edukalt ja vastus kaob tagasiteel. Mõlemad kasutajad ütlevad, et ühendus on ühesuunaline, ja mõlemad kirjeldavad paketti, mis kadus, seega kirjeldus üksi ei suuda neid eristada.

Küsige, kumb pool algatas ebaõnnestunud katse. See üks fakt eemaldab poole võimalikest põhjustest.

Seejärel kontrollige, et test kasutas kogu aeg samu hoste ja sama teenust. Ping ühelt poolt ja failijagamise ühendus teiselt poolt testivad kahte erinevat asja, ja lüüsist tehtud diagnostika võib valida tunneli aadressi, mida ükski kasutajaliiklus kunagi ei kasuta.

Esimene juhtum: tagasitee puudub

Kaugserver, mis vastab teise vaikelüüsi kaudu, võib päringu vastu võtta ja vastuse mujale marsruutida. Oleku jälgimisega tulemüürid viskavad siis asümmeetrilise vastuse kõrvale, sest see ei vasta loodud voolule, mis näeb täpselt välja nagu suund, mis kunagi ei töötanud. Tõlge lisab veel ühe variandi: sihtkoht näeb tõlgitud lähtet ja vastab sellele, nii et algse aadressi jaoks kirjutatud reegel ei klapi kunagi.

Kontrollige aadressi, mida sihtkoht pärast tõlget tegelikult näeb, ja tagasiteed selle aadressi jaoks, mitte algse alavõrgu jaoks.

Teine juhtum: poliitika ei lubanud seda kunagi

Vastupidine juhtum on lihtsam ja tavalisem, kui paistab: üks kontor peab kasutama keskteenust ja mitte kunagi keskmesse ühendusi algatama. See asümmeetria on teadlik juurdepääsuotsus ja tunnel töötab nii, nagu projekteeritud. Lugege juurdepääsupoliitikat enne, kui muudate ükskõik millist tunneli seadet. Milline suund oli kavatsetud, ütleb dokument, mitte paketipüük. Püük saab näidata ainult seda, mis juhtus, mitte seda, mis oli lubatud.

Kui kahesuunaline algatamine on tõesti vajalik, lisage konkreetse teenuse luba platvormi toetatud reeglistiku kaudu. Kõigi alavõrkude vastastikune usaldamine ühe rakenduse parandamiseks muudab kitsa nõude laiaks loaks ja seda vahetust vaadatakse hiljem harva üle.

Võrrelge enne ja pärast samadel hostidel

Jälgige sama katse mõlemat otsa, mitte kahte eraldi katset. Püüdke algatava hosti lüüsil ja sihtkohas, seejärel võrrelge, mis sisse tuli, mis välja läks ja millist aadressi kaugem pool nägi.

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

Kui sihtkoha püük näitab päringut ootamatu lähteaadressiga, on vastus tõlkes või marsruutimises, mitte tunneli turbepoliitikas. Kui sihtkoht ei näita üldse päringut, ei ületanud pakett kunagi kaitstud teed.

Pärast parandust korrake identset testi identsest hostist ja kinnitage, et kõrvaline juurdepääs on endiselt keelatud. Tunneli olek “established” ei toeta kumbagi järeldust üksi.