VPN med lokacijami deluje samo v eno smer: dve različni okvari

Lokacija A doseže B, B ne doseže A, in tunel je videti v redu v obe smeri. Preden se dotaknete tunela, ugotovite, katero okvaro v resnici imate. Nova povezava, začeta na B in zavrnjena, ter odgovor na povezavo, začeto na A, ki nikoli ne prispe, dajeta podobne pritožbe in popolnoma različne diagnoze. Eno je težava s pravilnikom ali potjo na poti; drugo je težava s povratno potjo ali stanjem za promet, ki je bil že dovoljen.

Ta razlika odloči, katere ukaze je vredno izvesti.

Dve okvari, ki sta videti enaki

V prvem primeru gostitelj B pošlje SYN na A in nič se ne vrne. V drugem gostitelj A uspešno odpre sejo in odgovor izgine na povratni poti. Oba uporabnika pravita, da je povezava enosmerna, in oba opisujeta paket, ki je izginil, zato ju sam opis ne more ločiti.

Vprašajte, katera stran je začela neuspešni poskus. To eno dejstvo odstrani polovico možnih vzrokov.

Nato preverite, ali je preizkus ves čas uporabljal iste gostitelje in isto storitev. Ping z ene strani in povezava do skupne mape z druge preizkušata dve različni stvari, diagnostika z prehoda pa lahko izbere naslov tunela, ki ga ne uporablja noben uporabniški promet.

Prvi primer: povratna pot manjka

Oddaljeni strežnik, ki odgovarja prek drugega privzetega prehoda, lahko zahtevo prejme in odgovor usmeri drugam. Požarni zidovi s sledenjem stanja nato zavržejo asimetrični odgovor, ker se ne ujema z vzpostavljenim tokom, kar je videti natanko kot smer, ki ni nikoli delovala. Prevajanje doda še eno različico: cilj vidi prevedeni vir in odgovori nanj, zato se pravilo, napisano za prvotni naslov, nikoli ne ujema.

Preverite naslov, ki ga cilj po prevajanju zares vidi, in povratno pot za ta naslov namesto za prvotno podomrežje.

Drugi primer: pravilnik tega ni nikoli dovolil

Nasprotni primer je preprostejši in pogostejši, kot je videti: ena pisarna naj bi uporabljala osrednjo storitev in nikoli ne bi smela začeti povezav v center. Ta asimetrija je namerna odločitev o dostopu in tunel deluje, kot je bil zasnovan. Preberite pravilnik o dostopu, preden spremenite katerokoli nastavitev tunela. Katera smer je bila mišljena, pove dokument, ne zajem paketov. Zajem lahko pokaže le, kaj se je zgodilo, ne pa, kaj je bilo dovoljeno.

Če je dvosmerno iniciiranje res potrebno, dodajte dovoljenje za določeno storitev prek podprtega nabora pravil platforme. Če vsako podomrežje postane medsebojno zaupanja vredno zaradi popravka ene aplikacije, se ozka zahteva spremeni v široko dovoljenje, in ta menjava je redko pozneje pregledana.

Primerjajte pred in po na istih gostiteljih

Opazujte oba konca istega poskusa, ne dveh ločenih poskusov. Zajemajte na prehodu gostitelja, ki začenja, in na cilju, nato primerjajte, kaj je vstopilo, kaj je izstopilo in kateri naslov je videla oddaljena stran.

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

Če zajem na cilju pokaže zahtevo z nepričakovanim izvornim naslovom, je odgovor v prevajanju ali usmerjanju, ne v varnostnem pravilniku tunela. Če cilj ne pokaže nobene zahteve, paket ni nikoli prestopil zaščitene poti.

Po popravku ponovite isti preizkus z istega gostitelja in potrdite, da je nepovezan dostop še vedno zavrnjen. Stanje tunela “established” samo po sebi ne podpira nobenega od obeh sklepov.