Veebiserver kaob, kui VPN-klient ühenduse loob

Teenus, mis kaob hetkel, mil VPN-klient ühenduse loob, ei ole tavaliselt blokeeritud, vaid vastab vale liidese kaudu. Päring saabub füüsilisele võrgukaardile, deemon kirjutab vastuse ja marsruutimistabel annab selle vastuse tunnelile, kuna tunnel on vaikimisi marsruudi üle võtnud. Kaugklient ei näe kunagi vastust ühendusele, mille ta avas, seega ootab ja teatab seejärel ajalõpust. Ükski tulemüürireegel ei osale selles ahelas kusagil.

Sümptom: päringud sisse, vastused valest uksest välja

Märk on sissetulev ühendus, mis ebaõnnestub, samal ajal kui kõik muu hostis töötab. Teine vihje on host, mis on LAN-ist kättesaadav, kuid mitte internetist, või selline, mis töötab kuni tunnel uuesti ühendub ja siis lakkab. Mõlemal juhul käitus edasisuund hästi ja tagasisuund mitte, mis viitab marsruutimise asümmeetriale, mitte poliitikale.

Kinnitage seda jälgides, kuhu vastus läheb, mitte jälgides, kuidas päring saabub.

Püüdke korraga nii füüsilisel liidesel kui ka tunnelseadmel. Kui päring ilmub füüsilisele liidesele ja vastus tunnelile, on diagnoos valmis. Vastus, mida ei ilmuta kusagil, tähendab, et teenus ei võtnud ühendust kunagi vastu, mis on eraldi uurimine eraldi põhjusega.

Kaks vaikimisi marsruuti ja üks marsruutimisotsus

Klient, kes paigaldab vaikimisi marsruudi, lisab teise kirje, mille mõõdik on LAN-i lüüsist parem. Mõned kliendid paigaldavad selle asemel kaks poolvahemiku marsruuti, mis katavad sama ruumi täpsemalt ja võidavad otsingu samamoodi. Mõlemad tehnikad jätavad tavalised väljuvad paketid valima tunneli liidese.

Selle valiku teeb ainult sihtkoht. Kerneli ei küsi, kust pakett tuli, kui poliitikareegel ei kästa tal seda teha. Nii antakse vastus avalikule kliendi aadressile tunnelile, mille kaugem ots saab paketi lähteaadressiga, mida ta ei oma, ning viskab selle ära või edastab selle kuhugi kasutusse. Linuxis võib range pöördtee filtreerimine visata algse päringu ära ka enne, kui teie teenus seda üldse näeb, mis näeb väljastpoolt identne välja. Mõlemad sümptomid tulevad samast puuduvast seosest sissetuleva voo ja selle vastuse vahel.

Tunnel käitub kogu aeg õigesti. Talle öeldi, et ta kannaks vaikimisi marsruuti, ja ta teeb täpselt seda.

Parandage tagasitee tunnelit lõhkumata

Parandamiseks on kolm vastupidavat viisi ja valik sõltub sellest, kui palju hosti enda liiklust peaks tunnelisse jääma. Teenuse sihtkoha või pordi välistamine on väikseim muudatus. Poliitikapõhine marsruutimine allika või märgi järgi on kõige täpsem. Allika tõlkimine on kõige jämedam ja kaks aastat hiljem kõige kergemini seletatav.

Valige selle järgi, mida host peab tegema, mitte selle järgi, millise katkendi te esimesena leidsite.

Sihtkoha välistamine sobib teenusele, millel on püsiv avalik aadress, ja deemoni sidumine füüsilise aadressiga kõigi aadresside asemel muudab selle välistamise turvalisemaks. Poliitikareegel, mis valib tabeli allika järgi, hoiab hosti enda ühendused tunnelis, samal ajal kui saadab teenuse vastused tagasi WAN-i lüüsi kaudu. Vastuste maskeerimine WAN-i liidesele jõuab sama teekonnani hinnaga, et kliendi aadress peidetakse teenuse logidest. Vaikimisi marsruudi ad hoc muutmine on diagnoos, mitte konfiguratsioon, sest klient kirjutab marsruudid igal taasühendusel uuesti.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Kui host marsruudib ka enda taga olevat LAN-i

Ühe hüppe võrra kaugemal naaseb sama asümmeetria rohkemate liikuvate osadega. Liiklus jõuab ruuterini internetist, edastatakse sisemisele seadmele ja selle seadme ainus tagasitee on tunnel, nii et vastus jõuab algse kliendini pakkuja enda aadressilt. Seejärel kohtab ühenduste jälgimine vastust voole, mille algust ta ei näinud, ja viskab selle ära. Klient seevastu ei näe üldse midagi.

Kaks muudatust parandavad selle: sihtkoha tõlkimine, et sissetulev ühendus jõuaks sisemise seadmeni, ja allika tõlkimine, et selle seadme vastus näeks välja, nagu tuleks see ruuterilt endalt.

Ruuteri püsivaras on tavaline väljend poliitikareegel, mis kinnitab pordiedastuse WAN-i poolele, samal ajal kui ruuteri enda liiklus sõidab tunnelis. Ilma allika tõlkimiseta on see vastus adresseeritud välisele kliendile ja sisemisel seadmel lihtsalt pole selle juurde marsruuti. Testige kolme asja eraldi, sest need ebaõnnestuvad erinevatel põhjustel: väljast saabuv ühendus, see, mille host ise algatab, ja nimeotsing.