WireGuard rokas sasveicināšanās strādā, pakalpojums ne

Rokas sasveicināšanās pabeidzas, klients rāda nesen pārsūtīšanas skaitītāju, un tomēr pieprasījums pakalpojumam tajā pašā serverī neizdodas. Šī kombinācija mulsina cilvēkus, jo tunelis acīmredzami strādā. Nav pierādīta vietējā piegāde: pakete ir sasniegusi resursdatoru, un tam vēl tā ir jāpieņem pareizajā ligzdā un jānodod procesam ar tiesībām atbildēt. Izskatiet šos trīs kontroles punktus pēc kārtas.

Apstājieties pie pirmā, kas nav izpildīts, un nepievienojiet noteikumus pārējiem.

Rokas sasveicināšanās pierāda tikai tuneli

WireGuard rokas sasveicināšanās izveido atslēgas starp vienaudžiem un atļauj datplūsmu diapazoniem, ko katrs vienaudzis uzskaitīja. Tā neko nepasaka par to, kuri procesi klausās serverī, un neko par to, vai resursdatora ugunsmūris pieņem paketes, kas adresētas kādai no tā paša adresēm.

Tieši pēdējā atšķirība visbiežāk tiek palaista garām: datplūsma uz pašu resursdatoru ir vietējā ievade, savukārt datplūsma, kas iet caur resursdatoru citur, ir pāradresācija. Tās apstrādā dažādas ugunsmūra ķēdes un dažādi iestatījumi. Nepareizas ķēdes pārbaude izmaksā pēcpusdienu un atgriež skaitītājus, kas izskatās nevainīgi.

Lasiet klausītāju un maršrutu

Klientā pārliecinieties, ka servera tuneļa adrese tiek maršrutēta tunelī. Serverī pārliecinieties, ka ligzda pastāv adresē, ko klients izmanto, un ka process aiz tās ir paredzētais.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Klausītājs adresē 127.0.0.1 nekad neatbildēs uz pieprasījumu, kas adresēts 10.66.0.1, lai ko atļautu ugunsmūris. Klausītājs vispārīgajā adresē atbildēs, ja vien noteikums to nebloķē. Tādējādi ligzdu saraksts atrisina pusi gadījumu pirms jebkura noteikuma pārbaudes. Ports un adrese kopā nosaka, vai pieprasījums var nonākt.

Salīdziniet adresi, ko izmanto klients, ar adresi, kas serverim patiešām ir tuneļa saskarnē. Novecojusi konfigurācija jebkurā pusē rada pieprasījumu, kas pareizi maršrutēts uz vienaudzi, kuram šādas adreses nav.

Piemērojiet noteikumus vietējai ievadei, nevis pāradresācijai

Ja pakete ierodas un ligzda pastāv, atlikušā robeža ir ievades politika. Noteikums, kas atļauj pāradresāciju, neatļauj vietējo piegādi, un noteikums, kas ierobežots ar vienu saskarni, var neatbilst gaidītajam tuneļa saskarnes nosaukumam.

Pārbaudiet ar vienu atļautu portu uz paredzēto pakalpojumu, nevis atverot resursdatoru. Pēc tam pārbaudiet pašas lietojumprogrammas autorizāciju: atļauto saraksts, konta prasība vai piesaiste konkrētam resursdatora nosaukumam var noraidīt pieprasījumu, ko tīkls veiksmīgi piegādāja.

Atstājiet sertifikātu pārbaudes vietā. Negaidīta sertifikāta identitāte ir informācija par to, kurš resursdators atbildēja, nevis šķērslis, kas jāapiet. Noklikšķināšana tam pāri paslēpj vienīgo pavedienu, kas identificē nepareizo pakalpojumu.

Atdaliet nosaukuma, lieluma un identitātes kļūmes

Pakalpojums, kas strādā pēc adreses, bet neizdodas pēc nosaukuma, ir DNS problēma, un labojums pieder klientam sūtītajai atrisinātāja konfigurācijai, nevis ugunsmūrim. Pakalpojums, kas atbild uz maziem pieprasījumiem, bet iestrēgst pie lielākām atbildēm, norāda uz paketes lielumu un MTU, kas ir pavisam cita izmeklēšana.

HTTPS kļūda, kas nosauc nepareizo resursdatoru, parasti nozīmē, ka pieprasījums sasniedza citu pakalpojumu, bieži tāpēc, ka starpniekserveris vai cits klausītājs pārvalda šo portu. Izlasiet sertifikāta subjektu un salīdziniet to ar resursdatoru, uz kuru gribējāt nokļūt. Šis salīdzinājums neko nemaksā un bieži pabeidz izmeklēšanu.

Pierakstiet, kurš kontroles punkts neizdevās: ligzda, ievades noteikums vai lietojumprogrammas politika. Šī viena rinda atšķir tīkla kļūmi no autorizācijas lēmuma. Tā arī neļauj nākamajam cilvēkam atvērt portus, kas nekad nav bijuši problēma.